Support for __VA_OPT__ in gcc

Support for __VA_OPT__ in gcc

[Edward Diener]

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. 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 ?

Re: Support for __VA_OPT__ in gcc

[Jonathan Wakely]

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.

Re: Support for __VA_OPT__ in gcc

[Edward Diener]

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 ?

Re: Support for __VA_OPT__ in gcc

[Jonathan Wakely]

On Mon, 30 Sep 2019 at 14:20, Edward Diener
<eldlistmailingz@tropicsoft.com> 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."

Since __VA_OPT__ has no meaning in C++ prior to C++20 (and is a
reserved name so can't conflict with anything else declared by users)
it clearly falls into the second category, "GNU extensions that do not
contradict it".

Re: Support for __VA_OPT__ in gcc

[Jonathan Wakely]

On Mon, 30 Sep 2019 at 14:34, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Mon, 30 Sep 2019 at 14:20, Edward Diener
> <eldlistmailingz@tropicsoft.com> 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."
>
> Since __VA_OPT__ has no meaning in C++ prior to C++20 (and is a
> reserved name so can't conflict with anything else declared by users)
> it clearly falls into the second category, "GNU extensions that do not
> contradict it".

As I already said, if you want a diagnostic use -pedantic (or
-pedantic-errors to make it ill-formed).

This is consistent with how other extensions have always been handled.

Re: Support for __VA_OPT__ in gcc

[Edward Diener]

On 9/30/2019 9:34 AM, Jonathan Wakely wrote:
> On Mon, 30 Sep 2019 at 14:20, Edward Diener
> <eldlistmailingz@tropicsoft.com> 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.

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.

Re: Support for __VA_OPT__ in gcc

[Jonathan Wakely]

On Mon, 30 Sep 2019 at 15:53, Edward Diener
<eldlistmailingz@tropicsoft.com> wrote:
>
> On 9/30/2019 9:34 AM, Jonathan Wakely wrote:
> > On Mon, 30 Sep 2019 at 14:20, Edward Diener
> > <eldlistmailingz@tropicsoft.com> 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.

Re: Support for __VA_OPT__ in gcc

[Edward Diener]

On 9/30/19 11:21 AM, Jonathan Wakely wrote:
> On Mon, 30 Sep 2019 at 15:53, Edward Diener
> <eldlistmailingz@tropicsoft.com> wrote:
>>
>> On 9/30/2019 9:34 AM, Jonathan Wakely wrote:
>>> On Mon, 30 Sep 2019 at 14:20, Edward Diener
>>> <eldlistmailingz@tropicsoft.com> 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.
> 

How do I find out, for a given gcc compiler product such as gcc-9.2, 
what the gnu extensions are when I specify '-std=c++nn' and when I 
specify '-std=gnu++nn' for any given valid 'nn' ? When I look in the 
documentation for '-std' in gcc-9.2 the only explanation I can see at 
https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/C-Dialect-Options.html#C-Dialect-Options 
does not give me that information. Does it exist somewhere online or in 
the gcc docs ?

Re: Support for __VA_OPT__ in gcc

[Jonathan Wakely]

On Tue, 1 Oct 2019 at 01:25, Edward Diener wrote:
> How do I find out, for a given gcc compiler product such as gcc-9.2,
> what the gnu extensions are when I specify '-std=c++nn' and when I
> specify '-std=gnu++nn' for any given valid 'nn' ? When I look in the
> documentation for '-std' in gcc-9.2 the only explanation I can see at
> https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/C-Dialect-Options.html#C-Dialect-Options
> does not give me that information. Does it exist somewhere online or in
> the gcc docs ?

The documented extensions (and when they are enabled) are covered in
https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/#toc-Extensions-to-the-C-Language-Family
and https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/#toc-Extensions-to-the-C_002b_002b-Language
(or just search for "extensions" in the TOC).

Re: Support for __VA_OPT__ in gcc

[Edward Diener]

On 10/1/2019 7:13 AM, Jonathan Wakely wrote:
> On Tue, 1 Oct 2019 at 01:25, Edward Diener wrote:
>> How do I find out, for a given gcc compiler product such as gcc-9.2,
>> what the gnu extensions are when I specify '-std=c++nn' and when I
>> specify '-std=gnu++nn' for any given valid 'nn' ? When I look in the
>> documentation for '-std' in gcc-9.2 the only explanation I can see at
>> https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/C-Dialect-Options.html#C-Dialect-Options
>> does not give me that information. Does it exist somewhere online or in
>> the gcc docs ?
> 
> The documented extensions (and when they are enabled) are covered in
> https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/#toc-Extensions-to-the-C-Language-Family
> and https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/#toc-Extensions-to-the-C_002b_002b-Language
> (or just search for "extensions" in the TOC).
> 

Thanks for the links. But I am trying to understand the difference 
between, let's say, '-std=c++17' and '-std=gnu++17'. Clearly they can 
not be offering the exact same gnu extensions, else there would not be 
two different settings for the C++ standard 2017 in gcc. You have said 
that '-std=c++17' is not necessarily just the C++17 standard but may 
also include some gnu extensions. So the gnu extensions included in 
'-std=c++17' must be different than the gnu extensions included in 
'-std=gnu++17'. How is it possible to find out the difference in gnu 
extensions between the two ? Is there any documentation that explains 
that difference, or is it left for the programmer to experiment and see 
what is there in each case ?

Re: Support for __VA_OPT__ in gcc

[Jonathan Wakely]

On Tue, 1 Oct 2019 at 15:59, Edward Diener
<eldlistmailingz@tropicsoft.com> wrote:
>
> On 10/1/2019 7:13 AM, Jonathan Wakely wrote:
> > On Tue, 1 Oct 2019 at 01:25, Edward Diener wrote:
> >> How do I find out, for a given gcc compiler product such as gcc-9.2,
> >> what the gnu extensions are when I specify '-std=c++nn' and when I
> >> specify '-std=gnu++nn' for any given valid 'nn' ? When I look in the
> >> documentation for '-std' in gcc-9.2 the only explanation I can see at
> >> https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/C-Dialect-Options.html#C-Dialect-Options
> >> does not give me that information. Does it exist somewhere online or in
> >> the gcc docs ?
> >
> > The documented extensions (and when they are enabled) are covered in
> > https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/#toc-Extensions-to-the-C-Language-Family
> > and https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/#toc-Extensions-to-the-C_002b_002b-Language
> > (or just search for "extensions" in the TOC).
> >
>
> Thanks for the links. But I am trying to understand the difference
> between, let's say, '-std=c++17' and '-std=gnu++17'. Clearly they can
> not be offering the exact same gnu extensions, else there would not be
> two different settings for the C++ standard 2017 in gcc.

Wrong. They could enable exactly the same set of extensions. It would
be confusing and annoying to users to *not* provide a -std=gnu++17
option given that we have -std=c++NN and -std=gnu++NN for every
previous standard. So it's wrong to assume "clearly" they can't mean
the same thing.

> You have said
> that '-std=c++17' is not necessarily just the C++17 standard but may
> also include some gnu extensions. So the gnu extensions included in
> '-std=c++17' must be different than the gnu extensions included in
> '-std=gnu++17'.

No, as above.

> How is it possible to find out the difference in gnu
> extensions between the two ? Is there any documentation that explains
> that difference, or is it left for the programmer to experiment and see
> what is there in each case ?

Read the manual sections I linked to. For each extension, if it
conflicts with the base standard it will only be enabled for the
gnu++NN modes, not the c++NN modes, and should be documented as such.

I'm not going to do reading that for you.

Re: Support for __VA_OPT__ in gcc

[Jonathan Wakely]

On Tue, 1 Oct 2019 at 16:36, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Tue, 1 Oct 2019 at 15:59, Edward Diener
> <eldlistmailingz@tropicsoft.com> wrote:
> >
> > On 10/1/2019 7:13 AM, Jonathan Wakely wrote:
> > > On Tue, 1 Oct 2019 at 01:25, Edward Diener wrote:
> > >> How do I find out, for a given gcc compiler product such as gcc-9.2,
> > >> what the gnu extensions are when I specify '-std=c++nn' and when I
> > >> specify '-std=gnu++nn' for any given valid 'nn' ? When I look in the
> > >> documentation for '-std' in gcc-9.2 the only explanation I can see at
> > >> https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/C-Dialect-Options.html#C-Dialect-Options
> > >> does not give me that information. Does it exist somewhere online or in
> > >> the gcc docs ?
> > >
> > > The documented extensions (and when they are enabled) are covered in
> > > https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/#toc-Extensions-to-the-C-Language-Family
> > > and https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/#toc-Extensions-to-the-C_002b_002b-Language
> > > (or just search for "extensions" in the TOC).
> > >
> >
> > Thanks for the links. But I am trying to understand the difference
> > between, let's say, '-std=c++17' and '-std=gnu++17'. Clearly they can
> > not be offering the exact same gnu extensions, else there would not be
> > two different settings for the C++ standard 2017 in gcc.
>
> Wrong. They could enable exactly the same set of extensions. It would
> be confusing and annoying to users to *not* provide a -std=gnu++17
> option given that we have -std=c++NN and -std=gnu++NN for every
> previous standard. So it's wrong to assume "clearly" they can't mean
> the same thing.
>
> > You have said
> > that '-std=c++17' is not necessarily just the C++17 standard but may
> > also include some gnu extensions. So the gnu extensions included in
> > '-std=c++17' must be different than the gnu extensions included in
> > '-std=gnu++17'.
>
> No, as above.
>
> > How is it possible to find out the difference in gnu
> > extensions between the two ? Is there any documentation that explains
> > that difference, or is it left for the programmer to experiment and see
> > what is there in each case ?
>
> Read the manual sections I linked to. For each extension, if it
> conflicts with the base standard it will only be enabled for the
> gnu++NN modes, not the c++NN modes, and should be documented as such.
>
> I'm not going to do reading that for you.

There are also Standard Library extensions. The -std=c++NN options
cause the __STRICT_ANSI__ macro to be defined, and certain Standard
Library extensions will be disabled when __STRICT_ANSI__ is enabled
(for example, is_floating_point<__float128>::value is true for gnu++NN
modes and false for strict modes). You can find those differences by
grepping the headers.