I have the following C++ code:
class A { protected: struct Nested { int x; }; }; class B: public A { friend class C; }; class C { void m1() { B::Nested n; // or A::Nested } }; Compiling this snippet with g++ 4.4, it does not make a difference whether I use B::Nested or A::Nested in m1. Clang accepts B::Nested, but does not compile if I A::Nested. Is that a bug in g++ or in clang?
According to the Standard, GCC is correct and Clang is wrong. It says at 11.2/4
A member m is accessible when named in class N if
- m as a member of N is protected, and the reference occurs in a member or friend of class N, or in a member or friend of a class P derived from N, where m as a member of P is private or protected
This is subject of this Clang bugreport, which prevents Clang from building Qt: http://llvm.org/bugs/show_bug.cgi?id=6840 . One Clang guy says
Actually, I intentionally haven't implemented this rule yet. It is either a drafting error or a horrible mistake. It neuters the entire 'protected' specifier, it makes the well-formedness of code dependent on the existence of completely unrelated classes, it imposes high costs on the implementation, and it's formally undecidable in the presence of templates.
In C++ friends are not-transitive. Friends of your friends are not necessarily my friends.
By making Nested protected in A, you indicate that all subclasses may use this element, but nobody else is allowed to use it. You could consider this is a kind of friend. A makes all subclasses friend regarding access to the Nested struct.
Now B makes C a friend, but this does not mean that C is also a friend of A. So C should have no access to Nested.
BUT: the behavior is changed from C++03. In C++03, a nested class is a full member of the enclosing class and so has full access rights. Friendship is still NOT transitive, but now member access is.
You may want to look at http://www.rhinocerus.net/forum/language-c-moderated/578874-friend-transitive-nested-classes.html, which explains a similar problem.
