On Mon, 30 Sep 2019 at 15:53, Edward Diener
<eldlistmailingz@xxxxxxxxxxxxxx> wrote:
>
> On 9/30/2019 9:34 AM, Jonathan Wakely wrote:
> > On Mon, 30 Sep 2019 at 14:20, Edward Diener
> > <eldlistmailingz@xxxxxxxxxxxxxx> wrote:
> >>
> >> On 9/30/2019 6:08 AM, Jonathan Wakely wrote:
> >>> On Sat, 28 Sep 2019 at 04:29, Edward Diener wrote:
> >>>>
> >>>> Given this program:
> >>>>
> >>>> #define PP_THIRD_ARG(a,b,c,...) c
> >>>> #define VA_OPT_SUPPORTED_I(...) PP_THIRD_ARG(__VA_OPT__(,),1,0,)
> >>>> #define VA_OPT_SUPPORTED() VA_OPT_SUPPORTED_I(?)
> >>>>
> >>>> #include <iostream>
> >>>>
> >>>> int main()
> >>>> {
> >>>> int result = VA_OPT_SUPPORTED();
> >>>> std::cout << result;
> >>>> return 0;
> >>>> }
> >>>>
> >>>> as a test for __VA_OPT__ support in a C++ compiler ( taken from
> >>>> https://stackoverflow.com/questions/48045470/portably-detect-va-opt-support
> >>>> )
> >>>> I have discovered that __VA_OPT__ support started with gcc-8.1.
> >>>
> >>> You could also consult
> >>> https://gcc.gnu.org/projects/cxx-status.html#cxx2a which notes that
> >>> the support is incomplete.
> >>>
> >>>> However
> >>>> I have also discovered that the support occurs no matter what the C++
> >>>> standard level is used for the compilation and not just when the option
> >>>> is 'std=c++2a'. In other words I can compile the program with
> >>>> 'std=c++03', link and run the program and the program will output 1,
> >>>> showing __VA_OPT__ support, rather than 0, which shows that __VA_OPT__
> >>>> is not supported.
> >>>>
> >>>> If I compile the above with any version of gcc lower than gcc-8.1 the
> >>>> program will outpyt 0 no matter what -std mode I use.
> >>>>
> >>>> Is this intended, that the C++20 __VA_OPT__ support works in all modes
> >>>> for gcc-8.1 and higher ?
> >>>
> >>> Yes, it's available as a GNU extension. You can get a diagnostic with
> >>> -std=c++14 -Wpedantic, but not with any -std=gnu++NN modes.
> >>
> >> I would strongly argue that if it is available as a GNU extension
> >> outside of normal C++20 support in gcc 8.1 on up then it should be
> >> available when specifying '-std=gnu++nn' but not available when
> >> specifying '-std=c++nn' for any C++ level except for '-std=c++2a'. Isn't
> >> the idea of gnu extensions that they should only be available when the
> >> programmer is using a gnu compiler mode, but not available if a
> >> programmer is using a c++ compiler mode ?
> >
> > No, absolutely not. The manual seems clear on that point:
> >
> > "The compiler can accept several base standards, such as ‘c90’ or
> > ‘c++98’, and GNU dialects of those standards, such as ‘gnu90’ or
> > ‘gnu++98’. When a base standard is specified, the compiler accepts all
> > programs following that standard plus those using GNU extensions that
> > do not contradict it. For example, -std=c90 turns off certain features
> > of GCC that are incompatible with ISO C90, such as the asm and typeof
> > keywords, but not other GNU extensions that do not have a meaning in
> > ISO C90, such as omitting the middle term of a ?: expression."
>
> So if a programmer compiles using "-std=c++11" gcc feels it has a
> perfect right to add to its C++11 implementation some feature of C++14 (
> or any other C++ standard for that matter ) which does not have any
> meaning in C++11, as a GNU extension, without the programmer having to
> specify "-std=gnu++11"? I understand that this is what is specified in
> your manual but I think such an approach is wrong. If I as a programmer
> specify a version of the standard, that is what I expect to get, not
> some amalgam of other standard constructs which would normally have no
> meaning in the C++ standard I am using.
Then your expectation is wrong and you should have read the manual properly :-P
If you as a programmer write valid C++11 then it will compile fine
with -std=c++11, and all C++11 constructs will behave as required by
the standard.
Again, if you want the compiler to pedantically refuse to accept
conforming extensions that's what -pedantic-errors is for (although
some extensions still won't be flagged even then, because GCC is not a
tool for enforcing strict conformance to a standard, it's a tool for
compiling code).
> I am arguing that in principle that gcc's approach, in this regard, is
> wrong from the end-users point of view while fully conceding that it is
> what is specified in your manual from which you quote above.
It's a decades-long policy, and you don't speak for all end users.
