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

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

On 06/07, Greg Troxel wrote:
> "J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
> 
> > It doesn't seem quite right to me that pkgsrc allows putting both a
> > language standard and features in USE_CXX_FEATURES.
> >
> >  For example:
> >
> >   USE_CXX_FEATURES= c++17 filesystem
> 
> Setting aside "feature foo is in N but we think it isn't", this is
> really ok; you might need a compiler that does c++NN, and you might need
> foo, for some foo NOT in NN but later).  If this were
> 
>    USE_CXX_FEATURES= c++11 filesystem
> 
> then I see nothing wrong with it.

Hmm, then maybe we just disagree.  I understand c++NN to indicate a
language standard as well as all the features that it supports.  If
you want to list features, you can.  If you want to declare a language
standard, you can.  But I don't see why you'd ever want to do both, and
mixing them seems not very clean to me.

> > If the standard is supposed to have the feature, then listing the
> > feature seems redundant.
> 
> "redundant" is not the issue.  It's a disagreement between
> 
>    c++17 means what it says, within reason
> 
>    c++17 means a big enough subset that "most" programs that say they
>    need c++17 build, and the things that are in c++17 but not needed for
>    "most" are in features.  (And some seem to think it's ok not to
>    document this, if I am following the comments, but I find it hard to
>    believe.)
> 
> > It seems that one of the following would be better:
> >
> > 1. Allow USE_CXX_FEATURES to contain either one standard or one or more
> >    features, but not both.
> 
> No, because "c++11 filesystem" is legit.

OK, well, I didn't know about this "two compiler standards for a single
application" thing, which seems crazy to me, but OK, so I'd have to
amend my "one standard" to "one or more standards".  But my preference
is still not to mix language standards and features, so I'd want your
"c++11 filesystem" to be written as (assuming that the filesystem
feature is supposed to be in c++17):

  USE_CXX_FEATURES= c++11 c++17

> > 2. Add USE_CXX_STD that can be set to one standard, and allow
> >    USE_CXX_FEATURES to contain only features, not a standard.  For
> >    example:
> >
> >      USE_CXX_STD= c++17
> 
> That won't help anything, because there are just a bunch of (to write it
> in pseudopython):
> 
>   if foo in USE_CXX_FEATURES:
>       GCC_REQD+=10
> 
> And, a package might need to run a compiler with --std=c++11 and also
> with --std=c++17 and having both documents that it needs a compiler that
> can be called either way.  Not that we have a compiler that does c++17
> and not c++11, but there is no conceptual bug in stating that you need
> both.
> 
> There is no practical problem blurring C++NN and features.  Nobody is
> confused by this.

I'm not saying anyone's confused by it, I'm just hijacking your thread
(sorry) and saying it doesn't seem that clean to me.

> The only problem is the disagreement about whether
> c++17 means "the entire standard, except perhaps for bizarre corner
> cases that nobody uses and gcc does not implement", "almost all of it,
> leaving out only things that are truly rare", or "most of it, but
> leaving out things that are fairly normal these days".
> 
> I (and Patrick Welche, if I read right) think that charconv and
> filesystem should be part of what you get with c++17.  I am ok with
> leaving parallelism_ts out for now, because we have 1 package that needs
> it, and I only learned it exists today; I don't know what others think.
> charconv and filesystem together with "pick limited versions" lead to
> "c++17 needs gcc10" and then parallelism_ts is probably ok anyway.

Yeah, I understand that.  I agree that since some of the c++NN standards
are not fully implemented by the compilers (and even what features
are implemented for a given standard could vary by compiler), what
features are considered to be in what standard just has to be defined
and documented so that it's clear, and then your use case of specifying
a standard would have worked had the feature been considered to be part
of the standard that you specified.  And if it hadn't, you would have at
least known that it wouldn't necessarily work.
 
> I think the number of people on 9 that can get away without building
> gcc10 and also build at least one program needing C++17 is very small.
> 
> If you are an actual such person, please speak up.

I'm not such a person, but I assume you mean a universal you here, not
just me.

Lewis