Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Does friendship extend to inner classes?

Reply
Thread Tools

Does friendship extend to inner classes?

 
 
Juha Nieminen
Guest
Posts: n/a
 
      06-10-2011
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?
 
Reply With Quote
 
 
 
 
Saeed Amrollahi
Guest
Posts: n/a
 
      06-10-2011
On Jun 10, 10:09*pm, Juha Nieminen <(E-Mail Removed)> wrote:
> * 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
 
Reply With Quote
 
 
 
 
Juha Nieminen
Guest
Posts: n/a
 
      06-11-2011
Saeed Amrollahi <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      06-12-2011
Ruben Safir <(E-Mail Removed)> wrote:
> 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.)
 
Reply With Quote
 
Geoff
Guest
Posts: n/a
 
      06-12-2011
On 11 Jun 2011 04:45:43 GMT, Juha Nieminen <(E-Mail Removed)>
wrote:

>Saeed Amrollahi <(E-Mail Removed)> wrote:
>> 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.


It's allowed in VS2010.
 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      06-12-2011
Juha Nieminen wrote:

> 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
 
Reply With Quote
 
Alf P. Steinbach /Usenet
Guest
Posts: n/a
 
      06-12-2011
* Kai-Uwe Bux, on 12.06.2011 23:01:
> Juha Nieminen wrote:
>
>> 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

--
blog at <url: http://alfps.wordpress.com>
 
Reply With Quote
 
Werner
Guest
Posts: n/a
 
      06-13-2011
On Jun 11, 10:41*pm, Ruben Safir <(E-Mail Removed)> wrote:

> 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
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      06-13-2011
Kai-Uwe Bux <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      06-13-2011
Juha Nieminen wrote:

> Kai-Uwe Bux <(E-Mail Removed)> wrote:
>> 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 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is it standard that inner class inherits the outer class' friendship? Qi C++ 4 05-01-2011 04:57 AM
How to extend inner classes? harold fellermann Python 0 12-21-2004 01:40 PM
How to extend inner classes? Kay Schluehr Python 0 11-28-2004 03:17 PM
How to extend inner classes? Kay Schluehr Python 1 11-28-2004 12:58 PM
How to extend inner classes? hfellerm@uni-osnabrueck.de Python 0 11-27-2004 05:02 PM



Advertisments