20. The Friend Function

Advanced perspective: privileged access needs a narrower reason than convenience

A friend declaration should expose one necessary relationship, not compensate for a confused interface

A friend function is a non-member that a class explicitly authorises to access its private and protected members. The declaration changes access; it does not turn the function into a member, supply a this pointer, make friendship reciprocal, pass the privilege to derived classes or extend it transitively to the friend's own friends.

That definition is necessary, but it does not decide when friendship is good design. The operative question is why this operation needs representation access while remaining outside the class. If the public interface already expresses the operation clearly and efficiently enough, an ordinary non-member preserves the boundary. If the operation belongs to one object's responsibility, a member may say so directly. Friendship is justified only when a non-member relationship and narrow private access are both part of the real design.

A hidden friend remains a namespace function

#include <iostream>

class Coordinate {
public:
    Coordinate(int x, int y) : x_{x}, y_{y} {}

    friend bool same_position(const Coordinate& left, const Coordinate& right) {
        return left.x_ == right.x_ && left.y_ == right.y_;
    }

private:
    int x_;
    int y_;
};

int main() {
    const Coordinate first{2, 5};
    const Coordinate second{2, 5};
    std::cout << std::boolalpha << same_position(first, second) << '\n';
}

same_position is defined inside the class definition, but it is not a member of Coordinate. Both operands are explicit parameters, there is no this, and the call uses ordinary function syntax. Its privilege is access to x_ and y_; its identity remains that of a function in the surrounding namespace.

Why does the unqualified call find it? A function first declared in this way is not made generally visible to ordinary unqualified lookup merely by the in-class friend definition. Argument-dependent lookup also searches functions associated with the argument types. Because both arguments are Coordinate objects, that lookup can find the hidden friend. The function compares 2 with 2 and 5 with 5, returns true, and std::boolalpha causes the word true to be printed.

Select member, non-member or friend by responsibility

An output operator often needs the stream as its left operand, which makes a non-member form natural. That does not automatically make it a friend. If public queries provide the complete printable state, the operator can be an ordinary client. A value comparison may likewise use public observations. Direct access can be useful where it avoids exposing representation solely for an operator, but the decision must name the dependency rather than repeat the word "idiomatic".

Non-member binary operators can also permit conversions on both operands where a member form would privilege the left-hand object. This supports symmetric arithmetic and comparison interfaces. It still does not mean every symmetric operator needs private access. Symmetry answers the member-versus-non-member question; representation needs answer the friend-versus-non-friend question.

Access is compile-time privilege, not exemption from the invariant

A friend can read and, when the object is non-const, modify private state within the rules of the language. It therefore joins the set of code that must preserve the class invariant. The compiler checks whether access is permitted; it does not check whether assigning a particular combination of private values makes domain sense.

This is why friendship should be reviewed with the class's constructors and mutating members. If a friend creates an invalid intermediate state that can escape, or retains an alias beyond the object's lifetime, the fact that the access was formally authorised offers no defence. Privilege identifies responsibility. It does not remove it.

A friend function is narrower than a friend class

friend class Inspector; grants every member function of Inspector access to the granting class's private and protected members. That includes methods added later. If only one inspection operation requires access, befriending the entire class authorises more code than the current requirement names.

A single friend function can express the narrower relationship. Sometimes two types are intentionally coupled so tightly that class friendship is accurate, such as an implementation helper whose whole responsibility depends on the representation. Even then, record the shared invariant and ownership model. "They are in the same subsystem" is an organisational fact, not an access policy.

Friendship is neither inherited nor transitive. If Inspector is a friend of Engine, a class derived from Inspector does not acquire that friendship merely by inheritance, and an Inspector friend does not become an Engine friend. It is also not reciprocal: Inspector may access Engine only because Engine granted that direction.

Hidden friends limit lookup, not access responsibility

Placing an operator as a hidden friend can keep it associated with the operand type and make ADL the normal discovery route. Defining it in the class also makes the definition inline in the relevant language sense, allowing identical definitions across translation units. Neither property guarantees that the compiler will inline each call, and neither makes private coupling cheaper to maintain.

Hidden friendship is particularly useful for operators that should participate when their type is an argument but should not become an unrelated candidate during ordinary namespace lookup. That is an overload-set decision. The function still needs a stable contract, correct constness and only the access its implementation genuinely requires.

Testing should normally observe the contract

Making a test fixture a friend can expose internal state quickly, but the test then depends on representation rather than solely on behaviour. Such tests may be justified for difficult low-level invariants or diagnostics. They should not replace contract tests that construct objects, perform public operations and observe promised results. A test suite that fails whenever two private members are reorganised can obstruct the very representation freedom encapsulation was meant to provide.

Before befriending a test, ask whether a safe public observation is already part of the type's real contract. Do not add a production setter solely for tests; that damages the interface. Equally, do not grant a whole testing class private access when one focused diagnostic function or internal assertion would meet the genuine need.

Transfer task: justify each privilege separately

Design an Interval type whose invariant is lower <= upper. The public interface already provides lower() and upper() value queries. You need an equality operator, an overlaps(left, right) operation, a stream output operator and a merge operation that returns a new interval when the inputs overlap.

Classify each operation as a member, ordinary non-member or friend non-member. For every proposed friend, name the representation fact that the public queries cannot safely or adequately provide. Then consider a serialiser class with ten methods, only one of which needs exact private representation. Decide whether to befriend the class, befriend one function or expose a different stable operation. Your answer must preserve the interval invariant and explain how a later representation change affects each selected form.

#include <algorithm>
#include <optional>
#include <ostream>
#include <stdexcept>

class Interval {
public:
    Interval(int lower, int upper)
        : lower_{lower}, upper_{upper}
    {
        if (lower > upper) {
            throw std::invalid_argument{"invalid interval"};
        }
    }

    [[nodiscard]] int lower() const noexcept { return lower_; }
    [[nodiscard]] int upper() const noexcept { return upper_; }

private:
    int lower_ = 0;
    int upper_ = 0;
};

bool operator==(const Interval& left, const Interval& right) noexcept
{
    return left.lower() == right.lower()
        && left.upper() == right.upper();
}

bool overlaps(const Interval& left, const Interval& right) noexcept
{
    return left.lower() <= right.upper()
        && right.lower() <= left.upper();
}

std::ostream& operator<<(std::ostream& out, const Interval& value)
{
    return out << '[' << value.lower()
               << ", " << value.upper() << ']';
}

std::optional<Interval> merge(
    const Interval& left,
    const Interval& right)
{
    if (!overlaps(left, right)) {
        return std::nullopt;
    }

    return Interval{
        std::min(left.lower(), right.lower()),
        std::max(left.upper(), right.upper())};
}

Friendship is a visible exception to an access boundary. Use it when the exception expresses a real non-member relationship that public behaviour cannot serve cleanly. If its only achievement is shorter typing around a private member, the code has gained privilege without gaining design.