Does friendship extend to inner classes?

[Juha Nieminen]

Consider the following:

//-----------------------------------------------
class A
{
class B
{
int i;
friend class A;
};

class C
{
void foo(B&);
};
};

void A::C::foo(B& b)
{
b.i = 5; // Allowed or not?
}
//-----------------------------------------------

It seems that gcc and Visual Studio disagree on this (gcc allows it,
Visual Studio issues an error). Which one is right?

 

[Saeed Amrollahi]

  Consider the following:

//-----------------------------------------------
class A
{
    class B
    {
        int i;
        friend class A;
    };

    class C
    {
        void foo(B&);
    };

};

void A::C::foo(B& b)
{
    b.i = 5; // Allowed or not?}

//-----------------------------------------------

  It seems that gcc and Visual Studio disagree on this (gcc allows it,
Visual Studio issues an error). Which one is right?

Hi
I tested and ran you code under GCC 4.6.0 and Visual Studio 2008.
Both allowed!
Actually, I wrapped your code to the following program:

#include <iostream>
class A
{
class B {
int i;
friend class A;
} b;

class C {
public:
void foo(B&);
} c;
public:
A() { c.foo(b); }
};

void A::C::foo(B& b)
{
b.i = 5; // Allowed or not?
std::cout << "It's allowed ...\n";
}

int main()
{
A a;
return 0;
}

The output is: "It's allowed ...
But, I surprised, because I found nothing in
Draft International Standard about such grants.
Indeed I found the following wording in FIDS: n2390:
section 9.7 paragraph 4:
Like a member function, a friend function (11.3) defined within
a nested class is in the lexical scope of that class; it obeys
the same rules for name binding as a static member function of
that class (9.4), but it has no special access rights to members
of an enclosing class.

HTH,
-- Saeed Amrollahi

 

[Juha Nieminen]

I tested and ran you code under GCC 4.6.0 and Visual Studio 2008.
Both allowed!

I should have specified that when I tried it (well, something similar)
with VS 2005, it gave an error about the private variable being
inaccessible.

 

[Juha Nieminen]

This code is useless since there is no public or private declarations,
no main and theorectically, friend is irrelavent to the example.

Thanks for your completely useless answer.

So what if there are no public or private declarations? Any member
declaration is by default private, so the 'private:' keyword would be
completely unnecessary. Compilation units do not need a 'main' function.
The 'friend' declaration is absolutely relevant to the question because
the question was: Should the given example code compile or not? (With
gcc it compiles, with VS2005 it doesn't.)

 

[Geoff]

I should have specified that when I tried it (well, something similar)
with VS 2005, it gave an error about the private variable being
inaccessible.

It's allowed in VS2010.

 

[Kai-Uwe Bux]

Consider the following:

//-----------------------------------------------
class A
{
class B
{
int i;
friend class A;
};

class C
{
void foo(B&);
};
};

void A::C::foo(B& b)
{
b.i = 5; // Allowed or not?
}
//-----------------------------------------------

It seems that gcc and Visual Studio disagree on this (gcc allows it,
Visual Studio issues an error). Which one is right?

The C++03 standard [11.4/2]:

Declaring a class to be a friend implies that the names of private and
protected members from the class granting friendship can be accessed in
declarations of members of the befriended class. [Note: this means that
access to private and protected names is also granted to member functions
of the friend class (as if the functions were each friends) and to the
static data member definitions of the friend class. This also means that
private and protected type names from the class granting friendship can be
used in the base-clause of a nested class of the friend class.

and now for the important sentence:

However, the declarations of members of classes nested within the friend
class cannot access the names of private and protected members from the
class granting friendship.

There is also an example:

Also, because the base-clause of the friend class is not part of its
member declarations, the base-clause of the friend class cannot access the
names of the private and protected members from the class granting
friendship. For example,
class A {
class B { };
friend class X;
};
class X : A::B { // ill-formed: A::B cannot be accessed
// in the base-clause for X
A::B mx; // OK: A::B used to declare member of X
class Y : A::B { // OK: A::B used to declare member of X
A::B my; // ill-formed: A::B cannot be accessed
// to declare members of nested class of X
};
};
]
...


This explanation in in a non-normative a note; and one could argue that the
interpretation that friendship does not extend to inner classes is a little
bit streched given the wording of the normative provision. C++0X has taken
that stance. In n3291, the corresponding clause [11.3/2] reads:

Declaring a class to be a friend implies that the names of private and
protected members from the class granting friendship can be accessed in
the base-specifiers and member declarations of the befriended class.
[ Example:
class A {
class B { };
friend class X;
};
struct X : A::B { // OK: A::B accessible to friend
A::B mx; // OK: A::B accessible to member of friend
class Y {
A::B my; // OK: A::B accessible to nested member of friend
};
};
-- end example ]
...

As one can see from the example, C++ is changing in this regard. That could
explain your observation that compilers disagree on this one.


Best,

Kai-Uwe Bux

 

[Alf P. Steinbach /Usenet]

* Kai-Uwe Bux, on 12.06.2011 23:01:

Consider the following:

//-----------------------------------------------
class A
{
class B
{
int i;
friend class A;
};

class C
{
void foo(B&);
};
};

void A::C::foo(B& b)
{
b.i = 5; // Allowed or not?
}
//-----------------------------------------------

It seems that gcc and Visual Studio disagree on this (gcc allows it,
Visual Studio issues an error). Which one is right?

The C++03 standard [11.4/2]:

Declaring a class to be a friend implies that the names of private and
protected members from the class granting friendship can be accessed in
declarations of members of the befriended class. [Note: this means that
access to private and protected names is also granted to member functions
of the friend class (as if the functions were each friends) and to the
static data member definitions of the friend class. This also means that
private and protected type names from the class granting friendship can be
used in the base-clause of a nested class of the friend class.

and now for the important sentence:

However, the declarations of members of classes nested within the friend
class cannot access the names of private and protected members from the
class granting friendship.

There is also an example:

Also, because the base-clause of the friend class is not part of its
member declarations, the base-clause of the friend class cannot access the
names of the private and protected members from the class granting
friendship. For example,
class A {
class B { };
friend class X;
};
class X : A::B { // ill-formed: A::B cannot be accessed
// in the base-clause for X
A::B mx; // OK: A::B used to declare member of X
class Y : A::B { // OK: A::B used to declare member of X
A::B my; // ill-formed: A::B cannot be accessed
// to declare members of nested class of X
};
};
]
...


This explanation in in a non-normative a note; and one could argue that the
interpretation that friendship does not extend to inner classes is a little
bit streched given the wording of the normative provision. C++0X has taken
that stance. In n3291, the corresponding clause [11.3/2] reads:

Declaring a class to be a friend implies that the names of private and
protected members from the class granting friendship can be accessed in
the base-specifiers and member declarations of the befriended class.
[ Example:
class A {
class B { };
friend class X;
};
struct X : A::B { // OK: A::B accessible to friend
A::B mx; // OK: A::B accessible to member of friend
class Y {
A::B my; // OK: A::B accessible to nested member of friend
};
};
-- end example ]
...

As one can see from the example, C++ is changing in this regard. That could
explain your observation that compilers disagree on this one.

I feel dizzy with all these to me arbitrary changes.

I remember, at meeting of Oslo C++ User Group some years ago the lecturer raised
a question about visibility for nested class friend thing.

And it turned out the rules had changed already two or three times -- then.

So I think this is a very practical question:

HOW TO DEAL WITH THE EVER CHANGING RULES?

It is like shooting at a moving target.

And since that is a classical problem, someone must (hopefully) found a solution?


Cheers,

- Alf

 

[Werner]

This code is useless since there is no public or private declarations,
no main and theorectically, friend is irrelavent to the example.

Not...

This merely implies everything is private (the difference between
keyword "class" and "struct"?). There needn't be a main
function to compile a file. Hence the code is perfectly
fine, in fact - I just compiled it at

http://www.comeaucomputing.com/tryitout/.

According to comeau, friendship is required for it to
compile.

Kind regards,

Werner

 

[Juha Nieminen]

As one can see from the example, C++ is changing in this regard. That could
explain your observation that compilers disagree on this one.

I suppose this means that, technically speaking, gcc (and apparently
newer versions of Visual Studio) are breaking the standard when they are
compiling in C++98/03 compatibility mode (ie. with no C++1x extensions
enabled)?

I suppose it also means that if you want to make your program
C++98-compliant, you will have to avoid using friendship like this
(something which can be broken accidentally because the compiler doesn't
protect you from the error).

Yes, this happened to me in a real project, and I was wondering which
one was being incorrect, gcc or VS2005. From what has been discussed it
seem that the latter is, technically speaking, acting properly.

 

[Kai-Uwe Bux]

I suppose this means that, technically speaking, gcc (and apparently
newer versions of Visual Studio) are breaking the standard when they are
compiling in C++98/03 compatibility mode (ie. with no C++1x extensions
enabled)?

[...]

I am not sure whether the situation is all that clear cut.

You snipped the quotes from the standard and the draft. Let me re-quote the
normative parts:

Standard [11.4/2]:

Declaring a class to be a friend implies that the names of private and
protected members from the class granting friendship can be accessed in
declarations of members of the befriended class. [Note: ... ]

Draft n3291 [11.3/2]:

Declaring a class to be a friend implies that the names of private and
protected members from the class granting friendship can be accessed in
the base-specifiers and member declarations of the befriended class.
[ Example: ... ]

As you can see, the normative relevant wording has _not_ changed with
respect to visibility of names in nested classes. Aparently, the committee
is of the opinion that the non-normative note in the C++03 standard was
errorneous. Hence, one can argue, g++ and newer versions of Visual Studio
are correct in _not_ rejecting your code even in strict c++03 mode; it was a
bug in the standard and not in the compilers.


Best,

Kai-Uwe Bux