This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: global scope in friends
- To: nathan at cs dot bris dot ac dot uk
- Subject: Re: global scope in friends
- From: Martin von Loewis <loewis at informatik dot hu-berlin dot de>
- Date: Thu, 4 Feb 1999 14:25:15 +0100
- CC: martin at mira dot isdn dot cs dot tu-berlin dot de, egcs at cygnus dot com, mes at ooc dot com
- References: <199902040738.IAA00858@mira.isdn.cs.tu-berlin.de> <36B9702C.81E0248A@acm.org>
> > 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