<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>People on enterprise distributions with ancient gcc have always
the possibility of building their gcc from source (that's fairly
easy. see bottom of <a class="moz-txt-link-freetext" href="https://gcc.gnu.org/wiki/InstallingGCC">https://gcc.gnu.org/wiki/InstallingGCC</a>. 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.</p>
<p>Let's maybe defer for this development cycle (3.13), but let's
put the topic on the table again for 3.14dev</p>
<p>Even</p>
<div class="moz-cite-prefix">Le 18/12/2025 à 18:50, Daniel Baston a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CA+K_q_o+Ms+tRH-Cddpa2kVnKD+yUXUKcJDas2bHVBzwFe8GRg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">> 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.<br>
<div><br>
</div>
<div>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
<a class="moz-txt-link-freetext" href="cpl::contains">cpl::contains</a>, <a class="moz-txt-link-freetext" href="cpl::starts_with">cpl::starts_with</a>, and <a class="moz-txt-link-freetext" href="cpl::ends_with">cpl::ends_with</a>.</div>
<div><br>
</div>
<div>Dan</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Thu, Dec 18, 2025 at
12:28 PM Howard Butler <<a href="mailto:howard@hobu.co"
moz-do-not-send="true" class="moz-txt-link-freetext">howard@hobu.co</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div style="line-break:after-white-space"><br>
<div>
<blockquote type="cite">
<div>On Dec 18, 2025, at 9:50 AM, Daniel Baston via
gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">gdal-dev@lists.osgeo.org</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">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. </div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div>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.</div>
<div><br>
</div>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">(Last month someone posted to this list
about build issues using gcc 8.5, for example [1]).
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>One of the questions on the 2025 GDAL User Survey <a
href="https://gdal.org/survey/" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://gdal.org/survey/</a>
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.</div>
<div><br>
</div>
<div><img alt="PastedGraphic-1.png"
src="cid:part1.12J3wplm.xjSct8fG@spatialys.com"
class=""></div>
<br>
<blockquote type="cite">
<div dir="ltr">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.</div>
</blockquote>
<div><br>
</div>
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.</div>
<div><br>
</div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>[1] <a
href="https://lists.osgeo.org/pipermail/gdal-dev/2025-November/061170.html"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.osgeo.org/pipermail/gdal-dev/2025-November/061170.html</a></div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>