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 <[email protected]> wrote:
On Dec 18, 2025, at 9:50 AM, Daniel Baston via gdal-dev
<[email protected]> 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.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
