Chapter 11: Friends

We're always interested in getting feedback. E-mail us if you like this guide, if you think that important material is omitted, if you encounter errors in the code examples or in the documentation, if you find any typos, or generally just if you feel like e-mailing. Send your email to Frank Brokken.
Please state the document version you're referring to, as found in the title (in this document: 5.2.0a) and please state the paragraph you're referring to.
All mail received is seriously considered, and new (sub)releases of the Annotations will normally reflect your suggestions for improvements. Except for the incidental case I will not otherwise acknowledge the receipt of suggestions for improvements. Please don't misinterpret this for lack of appreciation.

In all examples we've discussed up to now, we've seen that private members are only accessible by the code of their class. This is good, as it enforces the principles of encapsulation and data hiding: By encapsulating the data in an object we can prevent that code external to classes becomes implementation dependent on the data in a class, an by hiding the data from external code we can control modifications of the data, helping us to maintain data integrity.

In this short chapter we will introduce the friend keyword as a a means of allowing external functions to access the private members of a class. In this chapter the subject of friendship among classes is not discussed. Situations in which it is natural to use friendship among classes are discussed in chapters 16 and 18.

Friendship (i.e., using the friend keyword) is a complex and dangerous topic for various reasons:

Friendship, when applied to program design, is an escape mechanism allowing us to circumvent the principles of encapsulation and data hiding. The use of friends should therefore be minimized to situations where they can be used naturally.
If friends are used, realize that friend functions or classes become implementation dependent on the classes declaring them as friends. Once the internal organization of the data of a class declaring friends changes, all its friends must be recompiled (and possibly modified) as well.
Therefore, as a rule of thumb: don't use friend functions or classes.

Nevertheless, there are situations where the friend keyword can be used quite safely and naturally. It is the purpose of this chapter to introduce the required syntax and to develop principles allowing us to recognize cases where the friend keyword can be used with very little danger.

Let's consider a situation where it would be nice for an existing class to have access to another class. Such a situation might occur when we would like to give a class developed earlier in history access to a class developed later in history.

Unfortunately, while developing the older class, it was not yet known that the newer class would be developed. Consequently, no provisions were offered in the older class to access the information in the newer class.

Consider the following situation. The insertion operator may be used to insert information into a stream. This operator can be given data of several types: int, double, char *, etc.. Earlier (chapter 7), we introduced the class Person. The class Person has members to retrieve the data stored in the Person object, like char const *Person::getName(). These members could be used to `insert' a Person object into a stream, as shown in section 9.2.

With the Person class the implementation of the insertion and extraction operators is fairly optimal. The insertion operator uses accessor members which can be implemented as inline functions, effectively making the private data members directly available for inspection. The extraction operator requires the use of modifier members that could hardly be implemented differently: the old memory will always have to be deleted, and the new value will always have to be copied to newly allocated memory.

But let's once more take a look at the class PersonData, introduced in section 9.4. It seems likely that this class has at least the following (private) data members:

    class PersonData
    {
        private:
            Person *d_person;
            unsigned d_n;
    };

When constructing an overloaded insertion operator for a PersonData object, e.g., inserting the information of all its persons, one on each line, into a stream, the overloaded insertion operator is not so well implemented when the individual persons have to be accessed using the index operator, which will not generally be an inline function.

In cases like these, where the accessor and modifier members tend to become rather complex member functions, direct access to the private data members might improve efficiency. So, in the context of insertion and extraction, we are in that case looking for overloaded member functions implementing the insertion and extraction operations that have access to the private data members of the objects to be inserted or extracted. In order to implement such functions non-member functions must be given access to the private data members of a class. This is realized by using the friend keyword.

11.1: Friend-functions

Concentrating on the PersonData class, the starting point for the insertion operator is the following:

    ostream &operator<<(ostream &str, PersonData const &pd)
    {
        for (unsigned idx = 0; idx < pd.nPersons(); idx++)
            str << pd[idx] << endl;
    }

This implementation will perform its task as expected: using the (overloaded) insertion operator of the class Person, every Person stored in the PersonData object will be written to a separate line.

However, the repeated call to the index operator in the above implementation might reduce the efficiency of the implementation. Direct use of the array pointed to by Person *person might improve the efficiency of the above function.

At this point we should as ourselves if we consider the above operator<<() primarily an extension of the globally available operator<<() function, or in fact a member function of the class PersonData. Stated otherwise: assume we would be able to make operator<<() into a true member function of the class PersonData, would we object? Probably not, as the function's task is very closely tied to the class PersonData. In that case, the function can be made a friend of the class PersonData, thereby allowing the function access to the private data members of the class PersonData.

Friend functions must be declared as friends in the class interface. These friend declarations are in neither private nor public functions, and the friend declaration may therefore be placed anywhere in the class interface. Convention dictates that friend declaractions are listed directly at the top of the class interface. So, for the class PersonData we get:

    class PersonData
    {
        friend ostream &operator<<(ostream &stream, PersonData &pd);
        friend istream &operator>>(istream &stream, PersonData &pd);

        public:
            // rest of the interface
    };

The implementation of the insertion operator can now be altered in such a way that the insertion operator directly accesses the private data members of the provided PersonData object:

    ostream &operator<<(ostream &str, PersonData const &pd)
    {
        for (unsigned idx = 0; idx < pd.d_n; idx++)
            str << pd.d_person[idx] << endl;
    }

Once again, whether friend functions are considered acceptable or not remain a matter of taste: if the function is in fact considered a member function, but due to the C++ grammar the function cannot be defined as a member function, then there seems to be little reason not to use the friend keyword. In other cases, we think the friend keyword should be avoided, thereby respecting the principles of encapsulation and data hiding.

Explicitly note that if we want to be able to insert PersonData objects into ostream objects without using the friend keyword, the insertion operator cannot be placed inside the PersonData class. In this case operator<<() is a normal overloaded variant of the insertion operator, which must therefore be declared and defined outside of the PersonData class. This situation applies, e.g., to the example at the beginning of this section.

11.2: Inline friends

In the previous section we stated that friends can be considered member functions of a class, albeit that the characteristics of the function prevents us from actually defining the function as a member function. In this section we will follow this line of thought a little further.

If we actually consider the friend function a member function, we should be able to design a true member function that performs the same tasks as our friend function. For example, we could construct a function that inserts a PersonData object into an ostream:

    ostream &PersonData::insertor(ostream &str) const
    {
        for (unsigned idx = 0; idx < d_n; idx++)
            str << d_person[idx] << endl;
        return str;
    }

This member function can be called with a PersonData object to insert that object into the ostream str:

    PersonData
        pd;

    cout << "The Person-information in the PersonData object is:\n";
    pd.insertor(str);
    cout << "========\n";

Realizing that insertor() does the same thing as the overloaded insertor operator, that we defined as a friend, we could simply call the insertor() member in the code of the friend operator<<() function. Now this latter function has only one statement: it merely calls insertor(). Consequently:

The insertor() function may be hidden in the class by making it private, as there is not need for it to be called elsewhere
The operator<<() may be constructed as inline function, as it contains but one statement.

Thus, the relevant section of the class interface of PersonData becomes:

    class PersonData
    {
        friend ostream &operator<<(ostream &str, PersonData const &pd)
        {
            return pd.insertor(str);
        }
        private:
            ostream &insertor(ostream &str) const;
    };

The above example represents the final step in the development of friend functions. It allows us to formulate the following principle:

Although friend functions have access to private members of a class, this characteristic should not be used indiscriminately, as it results in a severe breach of the principle of encapsulation, thereby making non-class functions dependent on the implementation of the data in a class.
Instead, if the task a friend function performs, can be implemented in a true member function, it can be argued that a friend is merely a syntactical synonym or alias for this member function.
The interpretation of a friend function as a synonym for a member function is made concrete by constructing the friend function as an inline function.
As a principle we therefore state that friend functions should be avoided, unless they can be constructed as inline functions, having only one statement, in which an appropriate private member function is called.

Using this principle, we ascertain that all code that has access to the private data of a class remains confined to the class itself. This even holds true for friend functions, as they are defined as simple inline functions.