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

Chris Toney jctoney at gmail.com
Tue Dec 16 20:32:18 PST 2025


I'm positive on moving forward C++ standard at a decent cadence
especially for new features of interest to maintainers. Several
related projects are already at C++20 as mentioned. It has been widely
supported since at least 2021 [1]. Also alluded to, new features can
easily be checked before using to be sure they are widely implemented.

Chris

[1] https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-C_002b_002b-code-1

On Tue, Dec 16, 2025 at 3:48 PM Even Rouault via gdal-dev
<gdal-dev at lists.osgeo.org> wrote:
>
> Hi,
>
> any thoughts on :
>
> 1) updating our requirements to build GDAL to C++20 ?
>
> 2) and making use of it in our exported C++ headers ? (thus requiring
> C++ consumers of our API to also be C++20)
>
> Our current situation is C++17 required to build GDAL, and our C++
> exported headers are C++11 compatible (except some newer ones like
> gdalalgorithm_cpp.h, and some bits in )
>
> We already have 2 (optional) dependencies requiring C++20: Poppler and
> PDFium.  The next version of libarrow/libparquet will also require
> C++20. Note that C++20 is currenly only enabled in GDAL in the drivers
> whose dependencies require it.
>
> C++20 should not be an issue with the recent gcc/clang/MSVC. It would
> exclude the old-old-Ubuntu LTS 20.04 whose gcc 9 has only very partial
> support for it, but 20.04 standard support ended a few months ago, so
> not really relevant to consider for new GDAL version.  I'm not totally
> sure about Ubuntu 22.04. It has partial support with its default gcc 11,
> and improved one with gcc 12 that is also available. At the time GDAL
> 3.13 will be released, Ubuntu 26.04 will be released, so 24.04 will be
> old-LTS, and 22.04 old-old-LTS so discarding it if it becomes too much
> of an inconvenience seems fine to me.
>
> A few things that might be interesting in C++20 for our purposes:
>
> - bit manipulation offered by <bit>
> - std::span , particularly when bridging C and C++ API and passing
> non-constant size arrays around
> - defaulted C++20 == operator
> - std::string/string_view::starts_with/ends_with  (finally !)
> - container.contains() (finally !)
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev


More information about the gdal-dev mailing list