[gdal-dev] C++11 timeline

[Howard Butler]

> On Jan 5, 2017, at 9:08 AM, Kurt Schwehr <schwehr at gmail.com> wrote:
> 
> A ping to bring the topic of C++11 back to the front post holidays.
> 
> Thoughts?
> 
> On Fri, Dec 23, 2016 at 10:05 AM, Kurt Schwehr <schwehr at gmail.com> wrote:
> Hi all,
> 
> I would like to continue the C++11 discussion over the next couple weeks while many people are on slower development cycles with a proposal:
> 
> * Starting 2017-Mar-01, we switch GDAL trunk to require C++11 support from the compiler.
> * All prior branches would stick with their existing requirements for C++03 support
> 
> I had come up with a bunch of other things for a timeline, but they all see like noise after Even pointed out a whole ton of issues my thoughts.  This isn't as aggressive as I would like, but it would definitely help reduce the maintenance burden on humans and reduce the test load for continuous integration.  I removed explicit mention of OS or compiler versions which I had in my initial thoughts.
> 
> This would not be a free-for-all on C++11 features.  I think we would want to just start with removing some of the macros and workarounds that are currently in the code base.  Until we decide to go forward with other features, the main changes that would happen in C++ only code after this would be:
> 
> - Change NULL to nullptr
> - Drop virtual when using the override keyword (this becomes a req with C++17)
> - CPL_OVERRIDE -> override
> - Remove HAVE_CXX11 #ifs
> - And maybe some other things I missed
> 
> Once those are all done, we can then discuss when to allow things like unique_ptr internally (which will allow some serious simplification of some code).
> 
> Then at some later time, we can discuss what API changes to allow, when to require C++14, C++17, C11, etc.
> 
> Thoughts?

Kurt,

I meant to chime in on this. Thanks for the reminder. I wanted to put forward some of the experience we've had with PDAL on moving to C++11. I think the first question to ask is which compilers does GDAL expect to support, and then compute back from there as to whether or not enough C++11 support is covered by that set. PDAL's situation has been different than GDAL because we're a much younger project, we have a smaller set of compilers we have historically supported, and we have been a bit aggressive about moving forward. Even so, there are a few C++11'isms we don't use because we allow MSVC2013, for example. 

I agree that object lifetime management with unique_ptr and some systematic RAII would significantly improve GDAL's internals in terms of complexity and opportunity for bugs., but the refactoring itself is also likely to introduce a few bugs too. The benefits of following a few (not all) established modern C++ patterns would also help bootstrap developers into the GDAL codebase a bit faster as well. PDAL was happy to quit using Boost for its modern C++ library support, and our codebase has been better for it IMO. 

I'm not sure that GDAL has this luxury, however. The project would need to migrate with clear acknowledgement of the consequences -- the dropping of support for a number of now-working-but-quite-esoteric compilers. We wouldn't want to #ifdef hell the support of both. Maybe the size of the set that would be dropped is small. We need some feedback from people on the topic to gauge the temperature on it.

To migrate everything to C++11 just for the sake of it doesn't seem prudent, but I agree the long term benefits to the project could be significant. GDAL already has a number of CPL classes that are C++11 -like in terms of functionality they provide. There's been some benefit to doing our own thing and having control over it that might be given up with a move to C++11. 

What is the list of compilers that GDAL actively and accidentally supports? How will that be impacted by a C++11 requirement?

Howard