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

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

nia <nia%NetBSD.org@localhost> writes:

> On Thu, Jun 06, 2024 at 04:19:41PM -0400, Greg Troxel wrote:
>> I realize there are a lot of considerations, but if we document that
>> c++17 as a CXX_FEATURE should fully support the language, don't we need
>> to make it 8?
>
> We should not document this. It's an unreasonable demand.
> We don't document it for any other language standard, from c11
> to c++11.

That is the documented plan in compiler.mk, in general.

> It's basically "does compiler accept -std=blahblahblah".

This doesn't make sense to me at all.  gcc has a long tradition of just
starting to support a standard and adding --std early on.  That only
works because they are often first, so programs that are distributed
that want that standard are restricted to the subset gcc supports.  But
once gcc has implemented most, earlier compilers, while supporting
--std=, are no good.  We do not pick the first version where --std=foo
fails to cause an error, and I can't believe anybody would want to do
that.

I agree that "fully" is not the right word, and it's messy.

But "compiler accepts --std=foo" does not mean any of

  - a significant fraction of programs conforming to foo will be built
    (and built correctly)

  - a very high fraction will be ok

  - almost all programs that the community would agree are reasonably
    conforming to the standard, in a real-world sense of "what did you
    expect when you read it was a --std=foo prgoram" will be ok

It should be some flavor of "almost entirely, to the extent that when
someone reasonably says 'this program is in C++NN', then the compiler
will be adequate".  That leaves out bizarre edge cases that reasonable
people do not expect to work, basically things that people think should
not have been in the standard.  It doesn't leave out filesystem and
charconv, which the rest of the world apparently expects to be part of
C++17 and considers reasonable enough to use.

Do people seriously think that then the greater Free Software world uses
charconv or fileystem in a program documented as C++17, they believe
that they should point this out because it is fringe C++17?  I find that
not credible at all.

Flipping the whole question around, when packaging a program, there is
(if not a bug) a declaration by upstream what language the program is
written in.  We should be able to take this declaration and encode it,
and reliably have the package build on all platforms (at least relative
to this reason), not just the one the packager tested on.  That requires
a community wide definition of what C++NN means.