That's a possibility, but as longs as we require most of the code base to work with C++03, merging is going to be miserable. I'm suggesting we flip the requirement but make no immediate changes. GDAL builds cleanly with C++11 and C++14 right now, so it's just a matter of flipping the requirement and then deciding what and when we allow things to switch to new C++11 idiums. Initially, we can start by getting rid of ifdefs and doing a quick NULL -> nullptr (which is how gdal builds for me anyway with NULL defined to be nullptr).
On Thu, Jan 12, 2017 at 3:10 PM, Andrew Bell <[email protected]> wrote: > There's a lot of code to work on. Would it make sense just to make a > C++11 branch and get to work, merging into master whenever it seems the > right time? > > On Thu, Jan 12, 2017 at 2:42 PM, Nyall Dawson <[email protected]> > wrote: > >> On 13 January 2017 at 02:57, Greg Troxel <[email protected]> wrote: >> > >> > Kurt Schwehr <[email protected]> writes: >> > >> > If no other packages start to depend on unreleased GDAL, and the first >> > GDAL release requiring C++11 is a ways off, and by then enough other >> > things require it that a system not having a C++11 compiler is totally >> > non-viable, then this shouldn't cause problems for pkgsrc. >> > >> >> FYI - the upcoming QGIS 3.0 release has a hard c++11 requirement. Not >> sure how much that affects things, but certainly projects which >> utilise GDAL are already switching to c++11. >> >> Nyall >> _______________________________________________ >> gdal-dev mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > > > -- > Andrew Bell > [email protected] > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- -- http://schwehr.org
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
