Library of implicitly friend classes

Question

I am developing a C++ class library. The classes have "public" methods aimed at users, and "protected" ones supplying extra services reserved for internal use.

The classes do not derive from each other. In my current model, they need to be explicitly declared friends of each other. Is there a more compact/convenient way to achieve the same effect ?

---

Example:

class A
{
public:
    static int ExposedA() { return 1; }
    static int ExposedB();
    static int ExposedC();

private:
    static int Internal() { return 0; }
    friend class B;
    friend class C;
};

class B
{
public:
    static int ExposedA() { return 2 + A::Internal(); }
    static int ExposedB() { return 2; }
    static int ExposedC();

private:
    static int Internal() { return 0; }
    friend class A;
    friend class C;
};

class C
{
public:
    static int ExposedA() { return 3 + A::Internal(); }
    static int ExposedB() { return 3 + B::Internal(); }
    static int ExposedC() { return 3; }

private:
    static int Internal() { return 0; }
    friend class A;
    friend class B;
};

int A::ExposedB() { return 1 + B::Internal(); }
int A::ExposedC() { return 1 + C::Internal(); }
int B::ExposedC() { return 2 + C::Internal(); }

In practice, maintenance of the friends list is tedious, and forward references force to move the definitions out of the classes.

Answer 1

I reckon the short answer is "no".

In the comments (for anyone reading this in the future), you identified your problem as "a case of intentional strong coupling" as stated in an answer to this question (emphasis mine):

In general, friend classes are useful in designs where there is intentional strong coupling: you need to have a special relationship between two classes. More specifically, one class needs access to another classes's internals and you don't want to grant access to everyone by using the public access specifier.

The answer goes on to state:

The rule of thumb: If public is too weak and private is too strong, you need some form of selected access: either protected or friend (the package access specifier in Java serves the same kind of role).

In other words, if public doesn't work for you, and private doesn't work for you, you are left protected and friend. If you also can't use protected, then you are stuck with friend by the process of elimination. You can't change the language (unless you want to submit a paper to the committee, but that's a whole other topic entirely). You are left to juggle the these access specifiers around the best way you can.

To the question of which way is the best way to use these specifiers, I have no answer. It's nearly impossible for me to know what juggle combination will work best for your situation. So far, your solution seems to be the best. Nothing off the top of my head seems better, given your constraints.

---

it is internal to the class library. Users should have no access, libraries in the class should have mutual access.

If I'm understanding you correctly (and I may not be), I will say that you do have the (untested) option of having dual headers: one for you, and one for the end user. In your header, you can make the function public like this:

// YouB.h
class B
{
public:
    static int ExposedA() { return 2 + A::Internal(); }
    static int ExposedB() { return 2; }
    static int ExposedC();
    // This is a public function. Your compiler should have no problem with other classes using it
    static int Internal() { return 0; }
};

Then, you have a different header for your users:

// UserB.h
// YouB.h
class B
{
public:
    static int ExposedA() { return 2 + A::Internal(); }
    static int ExposedB() { return 2; }
    static int ExposedC();
private:
    // This is a now a private or protected function.
    // I haven't tested this, so I don't know if the other access thing will work,
    // but since it's solely an internal function, commenting it out or removing
    // it completely should work too
    static int Internal() { return 0; }
};