Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #90657 > unrolled thread

Compilers still disagree on the Most Vexing Parse

Back to article view | Back to comp.lang.c++

Contents

  Compilers still disagree on the Most Vexing Parse Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-06-16 14:23 -0700
    Re: Compilers still disagree on the Most Vexing Parse Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-06-16 23:45 -0400
      Re: Compilers still disagree on the Most Vexing Parse Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-26 02:31 -0700

#90657 — Compilers still disagree on the Most Vexing Parse

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

[toc] | [next] | [standalone]

#90659

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

[toc] | [prev] | [next] | [standalone]

#91186

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web