From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93158 invoked by alias); 30 Sep 2019 15:22:08 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 93145 invoked by uid 89); 30 Sep 2019 15:22:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=arguing, conceding, endusers, amalgam X-HELO: mail-wm1-f65.google.com Received: from mail-wm1-f65.google.com (HELO mail-wm1-f65.google.com) (209.85.128.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Sep 2019 15:22:05 +0000 Received: by mail-wm1-f65.google.com with SMTP id p7so13924767wmp.4 for ; Mon, 30 Sep 2019 08:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qz4m7kWuHZAJ968qIhzi1/Sj49XmPRqwGfz4FwdhVlo=; b=Of2dJ1SHy85Z1mYWn+VdenuXKLHwlcdG9r5rdDJMb1dKffDTXjFDlfsNCfzYkH9TJP hKpgCCLOZ/ZZAJ/ydlegfWnK7zLCiHohBOpUOcqAXV4vpniKuZRtwwz0qfr7wAi2Xx6d jdhWs4GJT5NLdq+9N0IbR8rj99cC0mSs3bTE2BC8lfzLxoth+EY7uFZdQQ+kr46eJqtS wA3kK6036g/Oafd/EAY83F82AcWjDX8mOMhf6A5iVRjU+ahGycQP6olcFptcwctj4rJ+ J8Ti/JmPNG4V2SmuMYcLBQtZLlVwCfmTD5YcfRPwb4AfVKgmH1EsyVRyYdshjaHS66Ge EmjA== MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Mon, 30 Sep 2019 15:22:00 -0000 Message-ID: Subject: Re: Support for __VA_OPT__ in gcc To: Edward Diener Cc: gcc-help Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00118.txt.bz2 On Mon, 30 Sep 2019 at 15:53, Edward Diener wrote: > > On 9/30/2019 9:34 AM, Jonathan Wakely wrote: > > On Mon, 30 Sep 2019 at 14:20, Edward Diener > > 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 > >>>> > >>>> int main() > >>>> { > >>>> int result =3D 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 opt= ion > >>>> is 'std=3Dc++2a'. In other words I can compile the program with > >>>> 'std=3Dc++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 mod= es > >>>> for gcc-8.1 and higher ? > >>> > >>> Yes, it's available as a GNU extension. You can get a diagnostic with > >>> -std=3Dc++14 -Wpedantic, but not with any -std=3Dgnu++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=3Dgnu++nn' but not available when > >> specifying '-std=3Dc++nn' for any C++ level except for '-std=3Dc++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 =E2=80=98c90= =E2=80=99 or > > =E2=80=98c++98=E2=80=99, and GNU dialects of those standards, such as = =E2=80=98gnu90=E2=80=99 or > > =E2=80=98gnu++98=E2=80=99. When a base standard is specified, the compi= ler accepts all > > programs following that standard plus those using GNU extensions that > > do not contradict it. For example, -std=3Dc90 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=3Dc++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=3Dgnu++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=3Dc++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.