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

[Daniel Baston]

> 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.
>
> [image: 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251218/d8352afe/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/20251218/d8352afe/attachment-0001.png>