Topic: Ambiguity with class-virt-specifiers


Author: pasa <pasa@lib.hu>
Date: Thu, 23 Jun 2011 13:44:18 CST
Raw View
"Inconnu" <shirarenai@yandex.ru>

(forwarding from clc++ to csc++ as a better fit group)

>>> What is defined in the declaration #1, according to the new standard:
>>> new empty final class N::X or variable N::final of type ::X?
>>
>>> struct X {int x.y; };
>>
>>> namespace N
>>> {
>>> struct X final {}; // #1
>>> }
>>
>> 2.11p2
>> <quote>
>> The identifiers in Table 3 have a special meaning when appearing in a
>> certain context. When referred to in the grammar, these identifiers are
>> used
>> explicitly rather than using the identifier grammar production. any
>> ambiguity as to whether a given identifier has a special meaning is
>> resolved
>> to interpret the token as a regular identifier.
>> Table 3 - Identifiers with special meaning
>> override final
>> </quote>
>>
>> According to that the ambiguity is resolved for the latter.

> OK. Then I have 2 questions more. 1) Isn't it too hard a task for a
> compiler to resolve such an ambiguity? Just imagine what it must do.
> 2) How to define empty final class X in the namespace N?

That is a good question. I add another one. Let's just have
struct S final {};

That supposed to be definiton of S, right?
Now let's insert before that
struct S;

Does that change the interpretation?

For these cases disambiguation can be done toward object by removing
the
class-key. I guess 2.11p2
was formed that way to guard the old code and not change meaning if
someone
used the new contextual keywords as identifiers. But this seem to
create
counter-intuitive thing like with the 'this really is a function
declaration' madness.

For this situation was the intent to use stuff between {} as decision-
maker?
And force tricks like

struct S final {public:};
?

If so, I'd suggest at least put in a note about that at the proper
place in
the standard text.


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: "Balog Pal" <pasa@lib.hu>
Date: Sun, 26 Jun 2011 13:52:22 CST
Raw View
"Inconnu" <shirarenai@yandex.ru>

(forwarding from clc++ to csc++ as a better fit group)

>>> What is defined in the declaration #1, according to the new standard:
>>> new empty final class N::X or variable N::final of type ::X?
>>
>>> struct X {int x.y; };
>>
>>> namespace N
>>> {
>>> struct X final {}; // #1
>>> }
>>
>> 2.11p2
>> <quote>
>> The identifiers in Table 3 have a special meaning when appearing in a
>> certain context. When referred to in the grammar, these identifiers are
>> used
>> explicitly rather than using the identifier grammar production. any
>> ambiguity as to whether a given identifier has a special meaning is
>> resolved
>> to interpret the token as a regular identifier.
>> Table 3 - Identifiers with special meaning
>> override final
>> </quote>
>>
>> According to that the ambiguity is resolved for the latter.

> OK. Then I have 2 questions more. 1) Isn't it too hard a task for a
> compiler to resolve such an ambiguity? Just imagine what it must do.
> 2) How to define empty final class X in the namespace N?

That is a good question. I add another one. Let's just have
struct S final {};

That supposed to be definiton of S, right?
Now let's insert before that
struct S;

Does that change the interpretation?

For these cases disambiguation can be done toward object by removing the
class-key. I guess 2.11p2
was formed that way to guard the old code and not change meaning if someone
used the new contextual keywords as identifiers. But this seem to create
counter-intuitive thing like with the 'this really is a function
declaration' madness.

For this situation was the intent to use stuff between {} as decision-maker?
And force tricks like

struct S final {public:};
?

If so, I'd suggest at least put in a note about that at the proper place in
the standard text.

--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]