Friend Function and Friend Classes

Programming Language & Its Applications — C++ Constructs with Objects and Classes, NEC licence examination syllabus (Nepal Engineering Council).

Friend Functions and Friend Classes

A deliberate, class-controlled exception to private access — granted, never taken.

🌍 Where this lives: the reason cout << myObject works for your own classes is a friend function. operator<< must take the stream as its left operand, so it cannot be a member of your class — yet it needs your private data to print it. Friendship is the only clean answer, and it is why virtually every serious C++ class you will read declares friend std::ostream& operator<<. Java has no equivalent and works around it with package-private access; C# uses internal. Search "why operator<< must be a non-member function" — the argument is short and it makes the whole feature click.

The mechanism

class Box { int width; public: Box(int w) : width(w) {} friend void inspect(const Box &b); ← friend FUNCTION friend class Inspector; ← friend CLASS }; void inspect(const Box &b) { std::cout << b.width; ← LEGAL: private access granted } KEY PROPERTIES: · The friend declaration goes INSIDE the class granting access. Access is GIVEN, never claimed. · It may appear in any section — public, private, or protected. The placement makes no difference at all. · A friend function is NOT a member: it has no `this`, is not called as obj.f(), and is not affected by the class's access specifiers. · Friendship is NOT symmetric. A friends B does NOT mean B friends A · Friendship is NOT transitive. A friends B, B friends C does NOT mean A friends C · Friendship is NOT inherited. A friend of Base is NOT a friend of Derived, and a friend of Base cannot see Derived's private members. A friend class means EVERY member function of that class gets access — a broad grant. Prefer friending a single function when that suffices.

friend_basics.cpp

#include <iostream>

class Account {
    std::string owner;
    double      balance;

public:
    Account(std::string o, double b)
        : owner(std::move(o)), balance(b) {}

    /* a single free function gets access */
    friend void audit(const Account &a);

    /* an entire class gets access */
    friend class Auditor;
};

/* NOT a member — no Account:: prefix, no this */
void audit(const Account &a) {
    std::cout << "  audit: " << a.owner
              << " holds Rs " << a.balance << "\n";
}

class Auditor {
public:
    /* every member of Auditor can see Account's privates */
    static bool suspicious(const Account &a) {
        return a.balance > 1000000;
    }
    static void adjust(Account &a, double delta) {
        a.balance += delta;         /* even writes */
    }
};

int main() {
    Account acc("Ram Bahadur", 50000);
    audit(acc);
    std::cout << "  suspicious? " << std::boolalpha
              << Auditor::suspicious(acc) << "\n";
    Auditor::adjust(acc, 2000000);
    audit(acc);
    std::cout << "  suspicious? "
              << Auditor::suspicious(acc) << "\n";
    return 0;
}
Output:
  audit: Ram Bahadur holds Rs 50000
  suspicious? false
  audit: Ram Bahadur holds Rs 2050000
  suspicious? true

The canonical use — operator<< and operator>>

Why operator<< CANNOT be a member function: When you write cout << obj the compiler looks for either cout.operator<<(obj) ← a member of ostream operator<<(cout, obj) ← a free function A member of YOUR class would have to be written obj << cout because a member's implicit first operand is *this. That is backwards from how everyone writes output. You cannot add a member to std::ostream — you do not own it. So the only option is a FREE function taking (ostream&, const YourType&) — which then needs friendship to reach private data. THE STANDARD SIGNATURE: friend std::ostream& operator<<(std::ostream &os, const T &obj); Both details matter: · takes ostream by NON-const reference (writing changes the stream's state) · RETURNS ostream& so that chaining works: cout << a << b << c parses as ((cout << a) << b) << c — each << must hand back the stream for the next one.

stream_ops.cpp

#include <iostream>
#include <sstream>

class Complex {
    double re, im;
public:
    Complex(double r = 0, double i = 0) : re(r), im(i) {}

    friend std::ostream& operator<<(std::ostream &os,
                                    const Complex &c);
    friend std::istream& operator>>(std::istream &is,
                                    Complex &c);
    /* a symmetric binary operator as a friend: both
       operands are treated identically, which reads
       better than making it a member */
    friend Complex operator+(const Complex &a, const Complex &b);
    friend bool operator==(const Complex &a, const Complex &b);
};

std::ostream& operator<<(std::ostream &os, const Complex &c) {
    os << c.re << (c.im < 0 ? " - " : " + ")
       << (c.im < 0 ? -c.im : c.im) << "i";
    return os;                    /* enables chaining */
}

std::istream& operator>>(std::istream &is, Complex &c) {
    is >> c.re >> c.im;
    return is;
}

Complex operator+(const Complex &a, const Complex &b) {
    return Complex(a.re + b.re, a.im + b.im);
}
bool operator==(const Complex &a, const Complex &b) {
    return a.re == b.re && a.im == b.im;
}

int main() {
    Complex p(3, 4), q(1, -2);

    /* chaining works because << returns ostream& */
    std::cout << "p = " << p << "\nq = " << q
              << "\np + q = " << p + q << "\n";

    std::cout << "p == q? " << std::boolalpha
              << (p == q) << "\n";

    /* reading works too */
    std::istringstream in("7 -8");
    Complex r; in >> r;
    std::cout << "read r = " << r << "\n";
    return 0;
}
Output:
p = 3 + 4i
q = 1 - 2i
p + q = 4 + 2i
p == q? false
read r = 7 - 8i

Checking: (3+4i) + (1−2i) = (3+1) + (4−2)i = 4 + 2i ✔ Why operator+ as a friend rather than a member? As a MEMBER: Complex operator+(const Complex &b) const; p + q → p.operator+(q) ✔ works 2.0 + p → 2.0.operator+(p) ✗ a double has no member functions As a FRIEND: friend Complex operator+(const Complex&, const Complex&); p + q → operator+(p, q) ✔ 2.0 + p → operator+(Complex(2.0), p) ✔ the converting constructor turns 2.0 into a Complex, then it matches So a non-member operator gives SYMMETRIC behaviour, where both operands get implicit conversions. For any commutative operator (+, *, ==) the free-function form is the correct design. This is a real, practical reason — not a stylistic preference.

This asymmetry is the strongest single argument for friend operators. A member operator privileges its left operand: only the left side gets to be this, and only the right side gets implicit conversion. For an operation that is mathematically symmetric, encoding that asymmetry in the design is simply wrong.

Worked example — friendship is not symmetric, transitive, or inherited

friend_limits.cpp

#include <iostream>

class B;    /* forward declaration */

class A {
    int secretA = 1;
public:
    friend class B;            /* B can see A's privates */
    void tryPeek(const B &b);  /* but can A see B's?   */
};

class C {
    int secretC = 3;
public:
    friend class B;            /* B is also C's friend */
};

class B {
    int secretB = 2;
public:
    void readA(const A &a) {
        std::cout << "  B reads A.secretA = "
                  << a.secretA << "\n";   /* ✔ granted */
    }
    void readC(const C &c) {
        std::cout << "  B reads C.secretC = "
                  << c.secretC << "\n";
    }
};

/* NOT SYMMETRIC: A is not B's friend, so this fails.
void A::tryPeek(const B &b) {
    std::cout << b.secretB;   error: 'int B::secretB' is
                              private within this context
} */
void A::tryPeek(const B &) {
    std::cout << "  A cannot read B — friendship is "
                 "one-directional\n";
}

/* NOT TRANSITIVE: B friends A and B friends C, but that
   gives A no access to C. */

class Base {
    int baseSecret = 10;
protected:
    int protectedVal = 20;
public:
    friend void showBase(const Base &b);
};
class Derived : public Base {
    int derivedSecret = 30;
};

void showBase(const Base &b) {
    std::cout << "  friend of Base reads baseSecret = "
              << b.baseSecret << "\n";
}
/* NOT INHERITED: showBase is not a friend of Derived.
void f(const Derived &d) { std::cout << d.derivedSecret; }
   error: private within this context                    */

int main() {
    A a; B b; C c; Derived d;
    b.readA(a);
    b.readC(c);
    a.tryPeek(b);
    showBase(d);      /* works: a Derived IS-A Base */
    return 0;
}
Output:
  B reads A.secretA = 1
  B reads C.secretC = 3
  A cannot read B — friendship is one-directional
  friend of Base reads baseSecret = 10

The three non-properties, stated as a table: SYMMETRIC? No. `friend class B;` in A grants B access to A. It grants A nothing. TRANSITIVE? No. If B is a friend of A, and D is a friend of B, D gets no access to A. INHERITED? No, in both directions: · a friend of Base cannot see Derived's own private members · a class derived from a friend does not inherit the friendship These are deliberate. Friendship is a targeted exception, so it must not leak. If it were transitive, granting access to one class could silently expose your internals to a class you have never heard of — which would make the whole feature unusable in practice.

Does friendship break encapsulation?

The standard exam answer, and the honest one, differ in emphasis. THE CASE AGAINST: A friend can read and write every private member. Add a friend and the set of code that can break your invariants grows beyond the class. THE CASE FOR: · The class GRANTS it. Nothing can take friendship, so the class still controls its own access list, and that list is visible in the class definition. · A friend is part of the class's INTERFACE, just written outside it. `operator<<` for your type is conceptually yours. · The alternative is worse: without friendship you would add public getters for every private member, which exposes the data to EVERYONE rather than to one named function. So the accurate statement: friendship does not break encapsulation, it EXTENDS the class boundary to explicitly named code. The leak would be public getters. USE FRIENDSHIP FOR: ✔ operator<< and operator>> ✔ symmetric binary operators (+, ==, <) ✔ two classes designed as a tightly-coupled pair (a container and its iterator) ✔ test fixtures needing to inspect internals AVOID IT WHEN: ✗ a public member function would do ✗ you are friending many unrelated classes — that is a design smell, and usually means the class has too many responsibilities

🌍 Go further: friendship is the C++ answer to a problem every language faces, and comparing the answers is instructive. Java has no friends, so libraries use package-private access — which means unrelated classes in the same package can see each other's internals, a broader grant than a named friend. C# has internal plus InternalsVisibleTo for test assemblies, which is very close to friendship. And C++ has a cleverer modern option for the operator case: the hidden friend idiom, where you define the friend function inside the class body so it is only findable by argument-dependent lookup. Search "hidden friend idiom C++" — it improves compile times and avoids polluting the enclosing namespace.

💡 Exam angle: define a friend function and state clearly that it is not a member — no this, not called with the dot operator, and its placement in public/private/protected is irrelevant. The three non-properties (not symmetric, not transitive, not inherited) are asked almost verbatim. The operator<< example is the standard program, and be ready to explain why it cannot be a member. Finish with the encapsulation discussion: friendship is granted by the class, so it extends rather than breaks the boundary.

Syllabus points

friend function & friend class

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.