Re: gdal 3.9.0, C++17, charconv, gcc7

[Greg Troxel <gdt%lexort.com@localhost>]

Thomas Klausner <wiz%gatalith.at@localhost> writes:

> On Thu, Jun 06, 2024 at 07:47:04PM -0400, Greg Troxel wrote:
>> Maybe we should have c++17lite and map that as we do, but really to
>> commit something with that when upstream says c++17, one has to test
>> with the forced-by-c++17 version of each compiler, and no higher, and
>> that's basically impossible on NetBSD 10 or current.
>
> I guess the way it is is because saying you need
> c++17-with-all-bells-and-whistles is impossible right now.

I can't really parse that.  And I'm not sure "bells and whistles" is
fair.  When a standard says a bunch of things are supposed to be there,
and some aren't, I think they can only be dismissed if they are fringe
and we are basically saying the standard is buggy for including them.

> From https://gcc.gnu.org/projects/cxx-status.html
>
> "C++17 Support in GCC
>
> GCC has almost full support for the previous revision of the C++ standard"
>
> i.e. even now, c++17 support in gcc is not "complete".
>
> So c++17 support would need to pull in gcc14+ even if many c++17
> programs could build with gcc10.

I don't think that's a reasonable or even accurate reading either.
Certainly, C++NN is not a reasonable standard, as evidenced by how gcc
is coping with it.  There are surely some fringe elements that don't
work still.  But, in gcc's table, most things work in 7, and there are
things that need 8.  I have not found any C++17 feature that is
documented by gcc to need a version > 8.

I am ok with sorting c++17 stuff that doesn't even work in 14 as fringe.
And, it seems unlikely to appear.  But pretty much nobody developing
code uses, tests with, or cares about 7.

> Perhaps we should rename c++17 to something else, but I think the
> situation right now is good enough, and you can check NetBSD 9 bulk
> reports to see if you need to add some more c++17 features to
> USE_CXX_FEATURES.

That is basically unsound.  You are suggesting that we code things in a
way that we don't know if they work and then go look for bugs.  That's a
recipe for having undetected bugs.  Really, upstream is (usually)
documenting a language standard they require, and we are putting that
into a variable.  Except that the variable doesn't mean what it
manifestly says, and what it is documented to mean.

I think early on, having things that are part of c++17 and fringe be
carved out may have made sense.  I think it can also make sense to have
them available separately so that an otherwise c++11 program that uses
<filesystem> can do so.

A key question in my mind is: If a program claims to need C++17, and
uses <charconv>, do the set of people that write in C++ say

  1) wow, that's odd; you really shouldn't use charconv in C++17, and if
  you do, you should explicitly call that out in NEWS

or

  2) That's unremarkable and nobody should be surprised.  <charconv> is
  part of C++17.

I think people are going to say 2.


And then: what is the goal?  To avoid requiring a compiler that supports
C++17 on NetBSD 9?  How many people are being saved from gcc10?  If they
need to build gcc10 anyway, then not requiring it is just causing pain
and not helping.