This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: global scope in friends


> >   friend A ::B::C();
> >   friend A::B ::C();
> or ill formed.

Right; this is an additional interpretation.

> My understanding is that the lhs of the :: is a class or namespace or empty,
> and the right is a member.

It seems that this depends on the context. In particular, the
declarator series of non-terminals have a parallel syntax to the
expression series. But yes: the general rule is
- optional ::
- optional namespace-names
- optional class-names

> :: left associates.

Where does it say that? In most cases, C and C++ can be parsed without
having the concept of assiciativity. In some case, the grammar is
ambiguous, and explicit ambiguity resolution is used.

> As that is :: we should treat it as a nested-name-specifier and so
> look up C in B and fail, giving a diagnostic.

On the implementation level, we have a shift-reduce conflict, as there
are legal cases were the declarator could start with a global-scope:

  friend void ::foo();

Fortunately, bison resolves this in the way you want: it will shift
the scope, instead of reducing A::B to a type.

> Presumably, to get 'friend A ::B::C();' one has to write 'friend A
> (::B::C)();' and to get 'friend A::B ::C();' one has to write
> 'friend A::B (::C)();'

This is a reasonable interpretation; yet I can't find justification
for it in the C++ standard. In case we've found a defect, it seems
reasonable to expect the resolution you propose.

Regards,
Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]