[gdal-dev] Updating requirements to C++20 for GDAL 3.13 ?

[Even Rouault]

There's no particular emergency in switching to C++20 but this was my 
reaction to seeing other pieces of the ecosystem (besides the ones I've 
already mentionned, there's QGIS too) having moved to it. The fact that 
we have those cpl:: emulations of part of it also shows it could be useful.

People on enterprise distributions with ancient gcc have always the 
possibility of building their gcc from source (that's fairly easy. see 
bottom of https://gcc.gnu.org/wiki/InstallingGCC. Come on: if you can 
build GDAL from source, you can pretty much build every other software 
in existence :-) :-)), or use some third party repositories with more 
modern compiler chains.

Let's maybe defer for this development cycle (3.13), but let's put the 
topic on the table again for 3.14dev

Even

Le 18/12/2025 à 18:50, Daniel Baston a écrit :
> > and the consequence of that is there is a lot of code in GDAL that 
> could be removed if it were more aggressive about taking advantage of 
> now-standard C++ facilities and constructs. Less code means less to 
> maintain and less to break.
>
> I agree with this as a principle, but looking at C++20 specifically I 
> don't see opportunity for significant code removal on the order of 
> C++11 or C++17. This thread brings up cpl::contains, cpl::starts_with, 
> and cpl::ends_with.
>
> Dan
>
> On Thu, Dec 18, 2025 at 12:28 PM Howard Butler <howard at hobu.co> wrote:
>
>
>>     On Dec 18, 2025, at 9:50 AM, Daniel Baston via gdal-dev
>>     <gdal-dev at lists.osgeo.org> wrote:
>>
>>     Any standard upgrade is a balance between making code easier to
>>     develop and maintain (better language features) vs reducing the
>>     number of people that are able to compile it themselves. Some of
>>     those who compile GDAL themselves are doing so because they work
>>     on older systems where a newer GDAL is not available via package
>>     manger.
>
>     The project cannot carry the burden of compatibility with old
>     compilers forever. One can always continue to use older versions
>     of the GDAL codebase with older compilers. That said, GDAL's
>     reputation has historically been very conservative about upgrading
>     the standard version it uses, and the consequence of that is there
>     is a lot of code in GDAL that could be removed if it were more
>     aggressive about taking advantage of now-standard C++ facilities
>     and constructs. Less code means less to maintain and less to break.
>
>>     (Last month someone posted to this list about build issues using
>>     gcc 8.5, for example [1]).
>
>     If your organization depends upon long term support of older
>     systems, it should be proactive about financially participating in
>     the GDAL Sponsorship Program or actively contributing pull
>     requests to maintain this compatibility. This stuff costs. My
>     observation is users in organizations that complain the loudest
>     for LTS backward compatibility for very old systems are also ones
>     that do not contribute to support it. Organizations that do value
>     it are either directly contributing to the codebase or providing
>     sponsorship through the maintenance program.
>
>     One of the questions on the 2025 GDAL User Survey
>     https://gdal.org/survey/ specifically asks the audience to rank
>     compatibility as a priority. We don't split out compiler standards
>     specifically, but I hope responses to this question guide us on
>     how long we have to hang on to things. Please make sure you've
>     filled out your survey responses this year to help us prioritize
>     this stuff.
>
>     PastedGraphic-1.png
>
>>     In this case I'm not sure the balance favors upgrading the
>>     standard, but that may be ignorance on my part about C++20 benefits.
>
>     I think the question is whether or not we bump the standard or
>     3.13 or wait until GDAL 3.14. C++20 is already *five years old*,
>     and our major release cadence is about 2x per year. IMO, guidance
>     from packagers on this topic should be most determinant. Greg
>     seemed apprehensive in his response. I'd like to hear from some
>     others before making the decision. Other packages with big
>     dependency impacts are also upgrading their C++ standard usage,
>     and packagers have the perspective and frustration managing all of
>     it together.
>
>>     [1]
>>     https://lists.osgeo.org/pipermail/gdal-dev/2025-November/061170.html
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251220/04fb003d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 16723 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251220/04fb003d/attachment-0001.png>