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