> 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.  > 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
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
