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

Groups > comp.lang.c++ > #91186

Re: Compilers still disagree on the Most Vexing Parse

Show all headers | View raw

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.

Back to comp.lang.c++ | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

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

csiph-web