Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

New York... when civilization falls apart, remember, we were way ahead of you. -- David Letterman


devel / comp.lang.c++ / Compilers still disagree on the Most Vexing Parse

SubjectAuthor
* Compilers still disagree on the Most Vexing ParseAndrey Tarasevich
`* Re: Compilers still disagree on the Most Vexing ParsePavel
 `- Re: Compilers still disagree on the Most Vexing ParseTim Rentsch

1
Compilers still disagree on the Most Vexing Parse

<u6ijs5$uj8a$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=416&group=comp.lang.c%2B%2B#416

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: andreyta...@hotmail.com (Andrey Tarasevich)
Newsgroups: comp.lang.c++
Subject: Compilers still disagree on the Most Vexing Parse
Date: Fri, 16 Jun 2023 14:23:16 -0700
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <u6ijs5$uj8a$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 16 Jun 2023 21:23:17 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="e7a563f006bb33915c1b5be4e499c21f";
logging-data="1002762"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19wZGwn22Vij4ZDBiGf2Uzl"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.10.0
Cancel-Lock: sha1:svmv5bLV94Y2JwAW0Pce34ujzi4=
Content-Language: en-US
 by: Andrey Tarasevich - Fri, 16 Jun 2023 21:23 UTC

Consider this

namespace N { const int C = 42; }

struct S { S(int) {} };

int main()
{
S s(S(N::C));
}

Both Clang and MSVC reject the declaration in `main`, since they insist
on interpreting it as a function declaration, and subsequently complain
about invalid parameter name syntax: qualified name is not allowed as a
function parameter name.

GCC quietly accepts the declaration inside `main` and treats it as an
object declaration. Of course, GCC also has to make an effort to
interpret it as a function declaration, but apparently when that attempt
fails, it falls back to interpreting it as an object declaration.

The standard says

http://eel.is/c++draft/dcl.ambig.res#1
1 The ambiguity arising from the similarity between a function-style
cast and a declaration mentioned in [stmt.ambig] can also occur in the
context of a declaration. In that context, the choice is between an
object declaration with a function-style cast as the initializer and a
declaration involving a function declarator with a redundant set of
parentheses around a parameter name. Just as for the ambiguities
mentioned in [stmt.ambig], the resolution is to consider any construct,
such as the potential parameter declaration, that could possibly be a
declaration to be a declaration.

I presume that the above "could possibly be" refers to purely
grammar-level correctness of the construct. And general declarator
syntax in the grammar actually allows qualified names in declarators (we
use them, for example, when defining class members outside of class
definition). So, I presume this is why Clang and MSVC believe that this
falls within the boundaries of that "could possibly be".

What about GCC, which accepts the code? Is this a consequence of GCC
sticking to a different interpretation of that "could possibly be"? Or
is this a GCC-specific "extension"?

--
Best regards,
Andrey

Re: Compilers still disagree on the Most Vexing Parse

<_%9jM.5489$HtC8.1764@fx36.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=418&group=comp.lang.c%2B%2B#418

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!nntp.club.cc.cmu.edu!45.76.7.193.MISMATCH!3.us.feeder.erje.net!feeder.erje.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx36.iad.POSTED!not-for-mail
Subject: Re: Compilers still disagree on the Most Vexing Parse
Newsgroups: comp.lang.c++
References: <u6ijs5$uj8a$1@dont-email.me>
From: pauldont...@removeyourself.dontspam.yahoo (Pavel)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Firefox/91.0 SeaMonkey/2.53.15
MIME-Version: 1.0
In-Reply-To: <u6ijs5$uj8a$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 59
Message-ID: <_%9jM.5489$HtC8.1764@fx36.iad>
X-Complaints-To: https://www.astraweb.com/aup
NNTP-Posting-Date: Sat, 17 Jun 2023 03:46:02 UTC
Date: Fri, 16 Jun 2023 23:45:43 -0400
X-Received-Bytes: 3342
 by: Pavel - Sat, 17 Jun 2023 03:45 UTC

Andrey Tarasevich wrote:
> Consider this
>
>   namespace N { const int C = 42; }
>
>   struct S { S(int) {} };
>
>   int main()
>   {
>     S s(S(N::C));
>   }
>
> Both Clang and MSVC reject the declaration in `main`, since they insist
> on interpreting it as a function declaration, and subsequently complain
> about invalid parameter name syntax: qualified name is not allowed as a
> function parameter name.
>
> GCC quietly accepts the declaration inside `main` and treats it as an
> object declaration. Of course, GCC also has to make an effort to
> interpret it as a function declaration, but apparently when that attempt
> fails, it falls back to interpreting it as an object declaration.
>
> The standard says
>
> http://eel.is/c++draft/dcl.ambig.res#1
> 1 The ambiguity arising from the similarity between a function-style
> cast and a declaration mentioned in [stmt.ambig] can also occur in the
> context of a declaration. In that context, the choice is between an
> object declaration with a function-style cast as the initializer and a
> declaration involving a function declarator with a redundant set of
> parentheses around a parameter name. Just as for the ambiguities
> mentioned in [stmt.ambig], the resolution is to consider any construct,
> such as the potential parameter declaration, that could possibly be a
> declaration to be a declaration.
>
> I presume that the above "could possibly be" refers to purely
> grammar-level correctness of the construct. And general declarator
> syntax in the grammar actually allows qualified names in declarators (we
> use them, for example, when defining class members outside of class
> definition). So, I presume this is why Clang and MSVC believe that this
> falls within the boundaries of that "could possibly be".
>
> What about GCC, which accepts the code? Is this a consequence of GCC
> sticking to a different interpretation of that "could possibly be"? Or
> is this a GCC-specific "extension"?

I am guessing, the former. I did not find a documented extension, even
though the most vexing parse is documented with several examples; so
leaving such an extension undocumented seems unlikely.

Also, my immediate interpretation of "could possibly be" is that it is
equivalent to "could be a part of a legal C++ program" and a legal C++
program has to be compilable. In other words, if the program can be
compiled in more than one ways, there is an ambiguity; else, there is no
ambiguity and there is nothing to resolve. Long story short, I am with
gcc here.

HTH,
-Pavel

Re: Compilers still disagree on the Most Vexing Parse

<86r0ovqasf.fsf@linuxsc.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=945&group=comp.lang.c%2B%2B#945

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: tr.17...@z991.linuxsc.com (Tim Rentsch)
Newsgroups: comp.lang.c++
Subject: Re: Compilers still disagree on the Most Vexing Parse
Date: Wed, 26 Jul 2023 02:31:12 -0700
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <86r0ovqasf.fsf@linuxsc.com>
References: <u6ijs5$uj8a$1@dont-email.me> <_%9jM.5489$HtC8.1764@fx36.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="5ba297a04e2080c4db730e1e3158367c";
logging-data="1542684"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19u62J6bk1I9Bg4tN8c1GWxPzxA7QZDV1w="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:oTL+5WNuB7Lb8bDgzpe8r+spPNY=
sha1:zWHvj0SOOY3Xth62KwB7GfCadXk=
 by: Tim Rentsch - Wed, 26 Jul 2023 09:31 UTC

Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes:

> Andrey Tarasevich wrote:
>
>> Consider this
>>
>> namespace N { const int C = 42; }
>>
>> struct S { S(int) {} };
>>
>> int main()
>> {
>> S s(S(N::C));
>> }
>>
>> Both Clang and MSVC reject the declaration in `main`, since they
>> insist on interpreting it as a function declaration, and
>> subsequently complain about invalid parameter name syntax: qualified
>> name is not allowed as a function parameter name.
>>
>> GCC quietly accepts the declaration inside `main` and treats it as
>> an object declaration. Of course, GCC also has to make an effort to
>> interpret it as a function declaration, but apparently when that
>> attempt fails, it falls back to interpreting it as an object
>> declaration.
>>
>> The standard says
>>
>> http://eel.is/c++draft/dcl.ambig.res#1
>> 1 The ambiguity arising from the similarity between a function-style
>> cast and a declaration mentioned in [stmt.ambig] can also occur in
>> the context of a declaration. In that context, the choice is between
>> an object declaration with a function-style cast as the initializer
>> and a declaration involving a function declarator with a redundant
>> set of parentheses around a parameter name. Just as for the
>> ambiguities mentioned in [stmt.ambig], the resolution is to consider
>> any construct, such as the potential parameter declaration, that
>> could possibly be a declaration to be a declaration.
>>
>> I presume that the above "could possibly be" refers to purely
>> grammar-level correctness of the construct. And general declarator
>> syntax in the grammar actually allows qualified names in declarators
>> (we use them, for example, when defining class members outside of
>> class definition). So, I presume this is why Clang and MSVC believe
>> that this falls within the boundaries of that "could possibly be".
>>
>> What about GCC, which accepts the code? Is this a consequence of GCC
>> sticking to a different interpretation of that "could possibly be"?
>> Or is this a GCC-specific "extension"?
>
> I am guessing, the former. I did not find a documented extension, even
> though the most vexing parse is documented with several examples; so
> leaving such an extension undocumented seems unlikely.
>
> Also, my immediate interpretation of "could possibly be" is that it is
> equivalent to "could be a part of a legal C++ program" and a legal C++
> program has to be compilable. In other words, if the program can be
> compiled in more than one ways, there is an ambiguity; else, there is
> no ambiguity and there is nothing to resolve. Long story short, I am
> with gcc here.

Humorous that the resolution of an ambiguity is written in such
a way that the disambiguiting condition itself has an ambiguity.


devel / comp.lang.c++ / Compilers still disagree on the Most Vexing Parse

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor