* Support for __VA_OPT__ in gcc @ 2019-09-28 3:28 Edward Diener 2019-09-30 10:08 ` Jonathan Wakely 0 siblings, 1 reply; 12+ messages in thread From: Edward Diener @ 2019-09-28 3:28 UTC (permalink / raw) To: gcc-help 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 ? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for __VA_OPT__ in gcc 2019-09-28 3:28 Support for __VA_OPT__ in gcc Edward Diener @ 2019-09-30 10:08 ` Jonathan Wakely 2019-09-30 13:20 ` Edward Diener 0 siblings, 1 reply; 12+ messages in thread From: Jonathan Wakely @ 2019-09-30 10:08 UTC (permalink / raw) To: Edward Diener; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for __VA_OPT__ in gcc 2019-09-30 10:08 ` Jonathan Wakely @ 2019-09-30 13:20 ` Edward Diener 2019-09-30 13:34 ` Jonathan Wakely 0 siblings, 1 reply; 12+ messages in thread From: Edward Diener @ 2019-09-30 13:20 UTC (permalink / raw) To: gcc-help 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 ? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for __VA_OPT__ in gcc 2019-09-30 13:20 ` Edward Diener @ 2019-09-30 13:34 ` Jonathan Wakely 2019-09-30 13:35 ` Jonathan Wakely 2019-09-30 14:53 ` Edward Diener 0 siblings, 2 replies; 12+ messages in thread From: Jonathan Wakely @ 2019-09-30 13:34 UTC (permalink / raw) To: Edward Diener; +Cc: gcc-help 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". ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for __VA_OPT__ in gcc 2019-09-30 13:34 ` Jonathan Wakely @ 2019-09-30 13:35 ` Jonathan Wakely 2019-09-30 14:53 ` Edward Diener 1 sibling, 0 replies; 12+ messages in thread From: Jonathan Wakely @ 2019-09-30 13:35 UTC (permalink / raw) To: Edward Diener; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for __VA_OPT__ in gcc 2019-09-30 13:34 ` Jonathan Wakely 2019-09-30 13:35 ` Jonathan Wakely @ 2019-09-30 14:53 ` Edward Diener 2019-09-30 15:22 ` Jonathan Wakely 1 sibling, 1 reply; 12+ messages in thread From: Edward Diener @ 2019-09-30 14:53 UTC (permalink / raw) To: gcc-help 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for __VA_OPT__ in gcc 2019-09-30 14:53 ` Edward Diener @ 2019-09-30 15:22 ` Jonathan Wakely 2019-10-01 0:25 ` Edward Diener 0 siblings, 1 reply; 12+ messages in thread From: Jonathan Wakely @ 2019-09-30 15:22 UTC (permalink / raw) To: Edward Diener; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for __VA_OPT__ in gcc 2019-09-30 15:22 ` Jonathan Wakely @ 2019-10-01 0:25 ` Edward Diener 2019-10-01 11:13 ` Jonathan Wakely 0 siblings, 1 reply; 12+ messages in thread From: Edward Diener @ 2019-10-01 0:25 UTC (permalink / raw) To: gcc-help 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 ? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for __VA_OPT__ in gcc 2019-10-01 0:25 ` Edward Diener @ 2019-10-01 11:13 ` Jonathan Wakely 2019-10-01 14:59 ` Edward Diener 0 siblings, 1 reply; 12+ messages in thread From: Jonathan Wakely @ 2019-10-01 11:13 UTC (permalink / raw) To: Edward Diener; +Cc: gcc-help 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). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for __VA_OPT__ in gcc 2019-10-01 11:13 ` Jonathan Wakely @ 2019-10-01 14:59 ` Edward Diener 2019-10-01 15:36 ` Jonathan Wakely 0 siblings, 1 reply; 12+ messages in thread From: Edward Diener @ 2019-10-01 14:59 UTC (permalink / raw) To: gcc-help 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 ? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for __VA_OPT__ in gcc 2019-10-01 14:59 ` Edward Diener @ 2019-10-01 15:36 ` Jonathan Wakely 2019-10-01 15:39 ` Jonathan Wakely 0 siblings, 1 reply; 12+ messages in thread From: Jonathan Wakely @ 2019-10-01 15:36 UTC (permalink / raw) To: Edward Diener; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for __VA_OPT__ in gcc 2019-10-01 15:36 ` Jonathan Wakely @ 2019-10-01 15:39 ` Jonathan Wakely 0 siblings, 0 replies; 12+ messages in thread From: Jonathan Wakely @ 2019-10-01 15:39 UTC (permalink / raw) To: Edward Diener; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-10-01 15:39 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-28 3:28 Support for __VA_OPT__ in gcc Edward Diener 2019-09-30 10:08 ` Jonathan Wakely 2019-09-30 13:20 ` Edward Diener 2019-09-30 13:34 ` Jonathan Wakely 2019-09-30 13:35 ` Jonathan Wakely 2019-09-30 14:53 ` Edward Diener 2019-09-30 15:22 ` Jonathan Wakely 2019-10-01 0:25 ` Edward Diener 2019-10-01 11:13 ` Jonathan Wakely 2019-10-01 14:59 ` Edward Diener 2019-10-01 15:36 ` Jonathan Wakely 2019-10-01 15:39 ` Jonathan Wakely
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).