On Mon, 30 Sep 2019 at 14:34, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> 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." > > 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.