Friends

What is a friend?

Something to allow your class to grant access to another class or function.

Friends can be either functions or other classes. A class grants access privileges to its friends. Normally a developer has political and technical control over both the friend and member functions of a class (else you may need to get permission from the owner of the other pieces when you want to update your own class).

Do friends violate encapsulation?

No! If they’re used properly, they enhance encapsulation.

“Friend” is an explicit mechanism for granting access, just like membership. You cannot (in a standard conforming program) grant yourself access to a class without modifying its source. For example:

    class X {
        int i;
    public:
        void m();       // grant X::m() access
        friend void f(X&);  // grant f(X&) access
        // ...
    };

    void X::m() { i++; /* X::m() can access X::i */ }

    void f(X& x) { x.i++; /* f(X&) can access X::i */ }

For a description on the C++ protection model, see D&E sec 2.10 and TC++PL sec 11.5, 15.3, and C.11.

You often need to split a class in half when the two halves will have different numbers of instances or different lifetimes. In these cases, the two halves usually need direct access to each other (the two halves used to be in the same class, so you haven’t increased the amount of code that needs direct access to a data structure; you’ve simply reshuffled the code into two classes instead of one). The safest way to implement this is to make the two halves friends of each other.

If you use friends like just described, you’ll keep private things private. People who don’t understand this often make naive efforts to avoid using friendship in situations like the above, and often they actually destroy encapsulation. They either use public data (grotesque!), or they make the data accessible between the halves via public get() and set() member functions. Having a public get() and set() member function for a private datum is okay only when the private datum “makes sense” from outside the class (from a user’s perspective). In many cases, these get()/set() member functions are almost as bad as public data: they hide (only) the name of the private datum, but they don’t hide the existence of the private datum.

Similarly, if you use friend functions as a syntactic variant of a class’s public access functions, they don’t violate encapsulation any more than a member function violates encapsulation. In other words, a class’s friends don’t violate the encapsulation barrier: along with the class’s member functions, they are the encapsulation barrier.

(Many people think of a friend function as something outside the class. Instead, try thinking of a friend function as part of the class’s public interface. A friend function in the class declaration doesn’t violate encapsulation any more than a public member function violates encapsulation: both have exactly the same authority with respect to accessing the class’s non-public parts.)

What are some advantages/disadvantages of using friend functions?

They provide a degree of freedom in the interface design options.

Member functions and friend functions are equally privileged (100% vested). The major difference is that a friend function is called like f(x), while a member function is called like x.f(). Thus the ability to choose between member functions (x.f()) and friend functions (f(x)) allows a designer to select the syntax that is deemed most readable, which lowers maintenance costs.

The major disadvantage of friend functions is that they require an extra line of code when you want dynamic binding. To get the effect of a virtual friend, the friend function should call a hidden (usually protected) virtual member function. This is called the Virtual Friend Function Idiom. For example:

class Base {
public:
  friend void f(Base& b);
  // ...
protected:
  virtual void do_f();
  // ...
};

inline void f(Base& b)
{
  b.do_f();
}

class Derived : public Base {
public:
  // ...
protected:
  virtual void do_f();  // "Override" the behavior of f(Base& b)
  // ...
};

void userCode(Base& b)
{
  f(b);
}

The statement f(b) in userCode(Base&) will invoke b.do_f(), which is virtual. This means that Derived::do_f() will get control if b is actually a object of class Derived. Note that Derived overrides the behavior of the protected virtual member function do_f(); it does not have its own variation of the friend function, f(Base&).

What does it mean that “friendship isn’t inherited, transitive, or reciprocal”?

Just because I grant you friendship access to me doesn’t automatically grant your kids access to me, doesn’t automatically grant your friends access to me, and doesn’t automatically grant me access to you.

• I don’t necessarily trust the kids of my friends. The privileges of friendship aren’t inherited. Derived classes of a friend aren’t necessarily friends. If class Fred declares that class Base is a friend, classes derived from Base don’t have any automatic special access rights to Fred objects.
• I don’t necessarily trust the friends of my friends. The privileges of friendship aren’t transitive. A friend of a friend isn’t necessarily a friend. If class Fred declares class Wilma as a friend, and class Wilma declares class Betty as a friend, class Betty doesn’t necessarily have any special access rights to Fred objects.
• You don’t necessarily trust me simply because I declare you my friend. The privileges of friendship aren’t reciprocal. If class Fred declares that class Wilma is a friend, Wilma objects have special access to Fred objects but Fred objects do not automatically have special access to Wilma objects.

Should my class declare a member function or a friend function?

Use a member when you can, and a friend when you have to.

Sometimes friends are syntactically better (e.g., in class Fred, friend functions allow the Fred parameter to be second, while members require it to be first). Another good use of friend functions are the binary infix arithmetic operators. E.g., aComplex + aComplex should be defined as a friend rather than a member if you want to allow aFloat + aComplex as well (member functions don’t allow promotion of the left hand argument, since that would change the class of the object that is the recipient of the member function invocation).

In other cases, choose a member function over a friend function.