Does friendship extend to inner classes?

Discussion in 'C++' started by Juha Nieminen, Jun 10, 2011.

  1. 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?
    Juha Nieminen, Jun 10, 2011
    #1
    1. Advertising

  2. On Jun 10, 10:09 pm, 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?


    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
    Saeed Amrollahi, Jun 10, 2011
    #2
    1. Advertising

  3. Saeed Amrollahi <> 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.
    Juha Nieminen, Jun 11, 2011
    #3
  4. Ruben Safir <> 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.)
    Juha Nieminen, Jun 12, 2011
    #4
  5. Juha Nieminen

    Geoff Guest

    On 11 Jun 2011 04:45:43 GMT, Juha Nieminen <>
    wrote:

    >Saeed Amrollahi <> 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.
    Geoff, Jun 12, 2011
    #5
  6. Juha Nieminen

    Kai-Uwe Bux Guest

    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
    Kai-Uwe Bux, Jun 12, 2011
    #6
  7. * 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>
    Alf P. Steinbach /Usenet, Jun 12, 2011
    #7
  8. Juha Nieminen

    Werner Guest

    On Jun 11, 10:41 pm, Ruben Safir <> 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
    Werner, Jun 13, 2011
    #8
  9. Kai-Uwe Bux <> 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.
    Juha Nieminen, Jun 13, 2011
    #9
  10. Juha Nieminen

    Kai-Uwe Bux Guest

    Juha Nieminen wrote:

    > Kai-Uwe Bux <> 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
    Kai-Uwe Bux, Jun 13, 2011
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Carlo v. Dango
    Replies:
    14
    Views:
    1,007
    Alex Martelli
    Oct 19, 2003
  2. Replies:
    0
    Views:
    315
  3. Kay Schluehr

    How to extend inner classes?

    Kay Schluehr, Nov 27, 2004, in forum: Python
    Replies:
    1
    Views:
    330
    Alex Martelli
    Nov 28, 2004
  4. Kay Schluehr

    How to extend inner classes?

    Kay Schluehr, Nov 28, 2004, in forum: Python
    Replies:
    0
    Views:
    327
    Kay Schluehr
    Nov 28, 2004
  5. Qi
    Replies:
    4
    Views:
    750
Loading...

Share This Page