C++ friend class and friend function: syntax and rules

A C++ friend class is a class that another class allows to use its private and protected members. The class granting access writes friend class Auditor; inside its own body, and a single function can be made a friend the same way. Friendship is one-way: not mutual, not inherited by derived classes, not passed on to a friend’s friends.

Here Account keeps its balance private and lets Auditor add two balances up:

#include <iostream>

class Account {
public:
    explicit Account(double start) : balance(start) {}

private:
    double balance;

    friend class Auditor;  // Auditor may use the private members
};

class Auditor {
public:
    double total(const Account& a, const Account& b) const {
        return a.balance + b.balance;  // allowed: Auditor is a friend
    }
};

int main() {
    Account savings(1200.0);
    Account checking(350.5);
    Auditor auditor;
    std::cout << "Total: " << auditor.total(savings, checking) << '\n';
}

It printed Total: 1550.5.

The samples are C++17, built with MSVC 19.44, Clang 19.1 (MSVC STL), GCC 16.2 and Clang 23.1 (libc++), and all four agreed on every one. friend has been in the language since C++98, so nothing here needs a newer standard; Since When lists what each standard added.

How do you declare a friend class in C++?

Put friend class Auditor; inside the class whose private members Auditor may use, as Account does above. Only the owner can grant access: no class can declare itself a friend of another from outside. A private member, usable only by the class’s own code (see how a C++ class is defined), is then open to every member function of Auditor too.

The line can go anywhere in the class body. Under private: or public: it means the same, since access labels have no effect on friend declarations, and Auditor need not be declared before it: all four compilers built both.

Without the friend line, the same access does not compile. Account never named Stranger:

class Stranger {
public:
    double peek(const Account& a) const {
        return a.balance;  // error: Stranger is not a friend
    }
};

Clang says 'balance' is a private member of 'Account'; MSVC reports the same mistake as error C2248.

What is a friend function?

A friend function is an ordinary function, not a member of the class, that the class lets use its private members. Declare it inside the class with friend, then define it outside like any other function, with no Account:: in front. It has no this, so it gets the accounts it compares as parameters:

class Account {
public:
    explicit Account(double start) : balance(start) {}

    friend bool richer(const Account& a, const Account& b);

private:
    double balance;
};

// A plain function: no Account:: in front, no this inside.
bool richer(const Account& a, const Account& b) {
    return a.balance > b.balance;  // allowed: richer is a friend
}

int main() {
    Account savings(1200.0);
    Account checking(350.5);
    std::cout << std::boolalpha;
    std::cout << richer(savings, checking) << '\n';  // true
    std::cout << richer(checking, savings) << '\n';  // false
}

It printed true, then false.

One member function of another class can be a friend too, once that class is defined:

class Account;  // declared, so Auditor can name it

class Auditor {  // defined before Account names its member
public:
    double total(const Account& a, const Account& b) const;
};

class Account {
public:
    explicit Account(double start) : balance(start) {}

private:
    double balance;

    // Only this one member function of Auditor is a friend.
    friend double Auditor::total(const Account& a,
                                 const Account& b) const;
};

double Auditor::total(const Account& a, const Account& b) const {
    return a.balance + b.balance;
}

With Auditor only declared, all four compilers rejected the friend line.

How do you print a class with operator<<?

Make operator<< a friend function and define it right inside the class. The stream sits on the left of std::cout << acct, so the operator cannot be a member of Account; as a friend it can still read balance:

class Account {
public:
    explicit Account(double start) : balance(start) {}

    friend std::ostream& operator<<(std::ostream& os,
                                    const Account& a) {
        return os << "Account with balance " << a.balance;
    }

private:
    double balance;
};

int main() {
    Account acct(1200.5);
    std::cout << acct << '\n';
}

All four printed Account with balance 1200.5. Defined inside the class, the function is still not a member; the compiler finds it through its argument’s class, so it needs no declaration outside. Operator overloading in C++ covers >> and the rest.

Is friendship mutual, inherited or transitive?

No, on all three counts. The standard says “Friendship is neither inherited nor transitive” ([class.friend]), and it is not mutual either: each access is granted by the class that owns the data.

Not mutual: Account names Auditor a friend, so Auditor may read balance, but Account gets nothing back. Auditor’s private notes stay closed to it:

class Account {
public:
    explicit Account(double start) : balance(start) {}

    std::string read_notes(const Auditor& au) const {
        return au.notes;  // error: Account is not Auditor's friend
    }

private:
    double balance;

    friend class Auditor;  // Auditor may read Account, not back
};

double Auditor::balance_of(const Account& a) const {
    return a.balance;  // allowed: Auditor is Account's friend
}

Not inherited: SeniorAuditor, a derived class of Auditor, does not inherit its friendship with Account:

class SeniorAuditor : public Auditor {
public:
    double review(const Account& a) const {
        return a.balance;  // error: friendship is not inherited
    }
};

Not transitive: a friend’s friend is not a friend. Auditor names Intern its own friend, so Intern may read Auditor’s notes, but not Account’s balance:

class Auditor {
    // ...
    friend class Intern;  // Intern may read Auditor's notes
};

class Intern {
public:
    std::string notes_of(const Auditor& au) const {
        return au.notes;  // allowed: Intern is Auditor's friend
    }
    double peek(const Account& a) const {
        return a.balance;  // error: a friend's friend is not a friend
    }
};

All four compilers rejected each line marked error with the ordinary private-access error Stranger got (for the first, naming Auditor’s notes); none has a special message about friendship. For SeniorAuditor or Intern to read balance in code of its own, Account itself would have to name it a friend; SeniorAuditor can still call the total it inherits, because that code is Auditor’s.

When should you use friend?

When code outside the class has to reach its private members and a public member function will not do:

• an operator with your object on the right, such as <<
• a class built as a pair with yours, such as a container and its iterator
• a test that has to see the private members

Otherwise give the class a public member function and leave friend out:

class Account {
public:
    explicit Account(double start) : balance(start) {}

    double get_balance() const { return balance; }  // no friend

private:
    double balance;
};

double total(const Account& a, const Account& b) {
    return a.get_balance() + b.get_balance();
}

It printed Total: 1550.5, as the friend version did. The isocpp FAQ on friends puts the rule in one line: “Use a member when you can, and a friend when you have to.” The C++ Core Guidelines go further in C.4: “Make a function a member only if it needs direct access to the representation of a class”, which is why total is a plain function.

Does friend break encapsulation?

Not by itself. The friend list is written inside the class, so the class still decides who touches its data; the isocpp FAQ answers “No! If they’re used properly, they enhance encapsulation.” The cost is reach: each friend is more code that may have to change when the private members change, so keep the list short.

Friend class or friend function: a checklist

More answers about the core language are in Language.