This is the mail archive of the gcc-bugs@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]
Other format: [Raw text]

[Bug c++/32204] friend from global namespace in template class ignored


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32204

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-27 13:13:13 UTC ---
(In reply to comment #8)
> In MSVC's defense, the standard is vague (or insufficient) in this regard for
> 'friend class' declarations. It says:
> 
> "If a friend declaration appears in a local class (9.8) and the name specified
> is an unqualified name, a prior declaration is looked up without considering
> scopes that are outside the innermost enclosing non-class scope."
> ...
> "For a friend class declaration, if there is no prior declaration, the class
> that is specified belongs to the innermost enclosing non-class scope, but if it
> is subsequently referenced, its name is not found by name lookup until a
> matching declaration is provided in the innermost enclosing nonclass scope."

That wording only applies to local classes, so is irrelevant here.  See 7.3.1.2
for the wording that covers non-local classes.

> The standard *should* specify whether the 'friend class declaration' case
> applies to qualified names. For example:

A friend class declaration using qualified name can't introduce a new name, it
can only refer to an existing class, so there must be a prior declaration.  See
footnote 95 from 7.3.1.2/3, which says that a friend declaration that first
declares a class must be unqualified.

> namespace ns {
>   class NSClass {
>     friend class ::SomeGlobalClass;
>   };
> }
> 
> Since ::SomeGlobalClass is qualified (via scope resolution operator) it
> explicitly belongs to the global namespace.

Yes, but a prior declaration in the global namespace must exist.

> However, the standard says that it
> shall "belong to the innermost enclosing non-class scope", which is a
> contradiction (or nonsense).

No, you've misread the standard.

I think the standard covers your case, GCC behaves correctly here.

This bug report is for a different case anyway, this is not the right place to
discuss it.


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