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 ?