Question

I’m trying to use an open-source project. Both the latest official (from a *.tar.gz file) and the bleeding-edge (from a SVN repository) versions do stuff like:

class Type1 {
    friend class Ridiculous;
    friend class Number;
    friend class Of_Friends;

    int  ImportantPrivateSemiSharedData;
};

 // In another header...

class Ridiculous {
    class Inner {
        void  MyFunc( Type1 &t )
        { /*do something with t.ImportantPrivateSemiSharedData*/ }
    };
};

AFAIK, marking class A as a friend of class B does not give any type associated with A friendship rights with B. Neither classes derived from A nor classes that are friendly with A get friendship with B. I would think that limitation also applies to inner classes.

I’m using a computer from 2002 stuck several operating-system versions back, while the program (and presumably its design team) is mainly on newer computers. Is my system compiler just old and busted, or are the new-hotness’s compilers allowing something they shouldn’t? Is this a C++11 change?

I just want to use this program, but I keep getting stuck on things like this. I’m already suspicious because the code is full of techniques like “private data with a ridiculous number of friends” and “inner classes everywhere,” which I think are code smells. The team is using these techniques together, but I think that they’re fundamentally incompatible since friendship doesn’t carry over and you can’t forward-declare inner classes.

(If it’s needed, I’m using Mac OS X Tiger 10.4.11/PowerPC 32-bit (a G4-equipped eMac). The program is LLVM and CLang (and LLVM Test Suite), trying from both the v3.0 archives and r153311 from Subversion. The compiler is the Apple-supplied GCC 4.0.1 with XCode 2.5.)

Addendum

Seeing the first responses, now I suspect that marking a class as a friend has two interpretations. Given a class A that has a friend class X in it, that declaration can grant access to:

1. a member function (static or special or neither) of X.
2. any function, including special ones, whose fully-qualified name has the
   fully-qualified name of X as a prefix.

I think my compiler uses the first definition, while the writers’ compiler uses the second. Has there been official word to which interpretation is correct? If so, when did the specification happen (C++98/03, a defect report, C++11)? I’ve always thought friendship meant the first version (including C++ material I’ve read); the second never entered my mind until now.

Answer 1

I think there are two issues at play here. One is that the code smells bad, as you say, and the second is that it doesn’t compile on your system. Regarding the smell, yes, excessive use of the friend keyword often indicates bad OO design. It is generally better to give an object what it needs to do its job rather than pull something out of it, which is essentially what friend lets you do.

Large numbers of inner classes, IMO, are not that bad, as they merely serve to keep classes within the scope of another. This helps keep the namespace less cluttered and allows you to use common names across different functional areas.

Regarding the compilation issue, I tried to reproduce this on my system (Ubuntu 10.04, gcc 4.4.3, two years old at this point), and created this sample program:

class A
{
    friend class B;

    int x;
};

class B
{
    class Inner
    {
    public:
        void foo(A& a)
        {
            a.x++;
        }
    };

public:
    void bbb()
    {
        Inner i;
        A a;

        i.foo(a);
    }
};

int main()
{
    B b;

    b.bbb();
}

This compiled with no errors or warnings. I initially had nothing marked public, but I needed to add bbb() to create an instance of class Inner, and I had to add a public method of Inner so I could invoke it to do something with an A.

The upshot is that I think your development system is out of date. The main developers clearly have no problem compiling their code, so the difference has to be with your system, or else they have configured their systems in a way that they are not telling you about. That being said, I think they could do more to make their code more portable and easier to build. In an open source project, that is to be expected if you want others to contribute.