public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "scottbaldwin at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/32204] friend from global namespace in template class ignored Date: Sat, 27 Oct 2012 08:52:00 -0000 [thread overview] Message-ID: <bug-32204-4-egmSTzEdpa@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-32204-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32204 --- Comment #8 from etherice <scottbaldwin at gmail dot com> 2012-10-27 08:52:10 UTC --- 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." The standard *should* specify whether the 'friend class declaration' case applies to qualified names. For example: namespace ns { class NSClass { friend class ::SomeGlobalClass; }; } Since ::SomeGlobalClass is qualified (via scope resolution operator) it explicitly belongs to the global namespace. However, the standard says that it shall "belong to the innermost enclosing non-class scope", which is a contradiction (or nonsense). This is why the standard *should* specify a case for qualified vs unqualified names in friend class declarations (as it does for normal friend declarations). The assumption MSVC makes not only seems reasonable, but is also convenient for developers as it allows *hidden* forward declarations of names in outer namespaces. This avoids having to make an unnecessary explicit forward declaration. Perhaps GCC should "interpret" this part of the standard similarly.
next prev parent reply other threads:[~2012-10-27 8:52 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-32204-4@http.gcc.gnu.org/bugzilla/> 2011-01-17 6:48 ` jag-gnu at jag dot dreamhost.com 2012-03-26 21:24 ` dpiepgrass at mentoreng dot com 2012-03-26 21:32 ` dpiepgrass at mentoreng dot com 2012-03-26 23:52 ` redi at gcc dot gnu.org 2012-03-27 0:44 ` redi at gcc dot gnu.org 2012-10-27 8:12 ` scottbaldwin at gmail dot com 2012-10-27 8:52 ` scottbaldwin at gmail dot com [this message] 2012-10-27 13:13 ` redi at gcc dot gnu.org 2012-10-27 13:39 ` scottbaldwin at gmail dot com 2007-06-04 12:01 [Bug c++/32204] New: " klaus dot kretschel at dlr dot de 2009-12-08 23:11 ` [Bug c++/32204] " redi at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-32204-4-egmSTzEdpa@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).