A nonmember operation sometimes needs to inspect two objects' private representation without exposing that representation through public setters. Friendship can grant the required access deliberately. It is not an automatic loss of encapsulation, but a broad grant can make invariants harder to maintain. The class should decide who needs privileged access and why.
This guide uses C++17. You will define a hidden friend that compares batch identity and a friend collaborator that performs a bounded reservation. The examples keep state changes controlled. Friendship is discussed as an access-design tool rather than a shortcut for reaching any private field from unrelated code.
Friendship grants access without membership
A friend function remains a nonmember function even when its declaration or definition appears inside a class. It does not receive an implicit this pointer and needs explicit objects as arguments. The access grant permits it to read or modify private and protected members of the granting class.
The granting class controls that permission. A function cannot simply declare itself another class's friend from outside. The placement under public, protected or private does not change the meaning of the friend declaration. Review the grant as part of the class's interface design. If an operation can be implemented clearly through an existing public contract, friendship may be unnecessary; if it needs a representation-specific cooperative operation, a narrow friend can avoid exposing general-purpose mutation.
Friendship is not symmetric or transitive
If Warehouse declares Auditor a friend, Auditor can access Warehouse's private members. That does not automatically let Warehouse access Auditor's private members. If Auditor then grants another class friendship, the new class does not become a friend of Warehouse.
Friendship also does not automatically pass to derived classes. A collaborator's subclass does not inherit the original access grant merely through inheritance. These restrictions keep the permission specific, but a friend class still gives all of its relevant member functions privileged access. When only one operation needs access, a friend function or selected member declaration can express a narrower relationship. Avoid expanding a grant simply to silence a new compile error without reviewing the new responsibility.
Access does not excuse invariant violations
A friend can bypass public mutation methods, so its implementation must preserve the same state rules. A reservation service that accesses stock directly must still reject negative requests and insufficient stock. Private access is permission to implement a trusted collaboration, not evidence that every assignment is correct.
Avoid a generic friend utility that serializes every private member, changes arbitrary state or logs sensitive representation without a clear contract. Such a grant can create hidden dependencies between unrelated components. Prefer an explicit operation with a small responsibility and review it together with the class's invariants. Tests should verify failed operations leave state unchanged as well as successful operations producing the intended result.
Friend operators can support symmetric APIs
A nonmember binary operator can treat both operands symmetrically and work with appropriate conversions under overload resolution. Friendship is sometimes useful when that operation needs private data. This explains common stream insertion and arithmetic designs, but does not mean every operator must be a friend.
Operators should keep an intuitive meaning and preserve the class's invariants. Do not overload a familiar operation to perform surprising network work or unrelated mutation. If equality is implemented as a friend, ensure it agrees with the intended value policy and any associated hashing. Representation access makes an implementation possible; the semantic contract determines whether it is a good interface.
Keep privileged dependencies reviewable
A representation change can require updates in friend functions and classes. Keep those collaborators close enough in the codebase that the relationship is easy to inspect. A large number of unrelated friends can signal that the class boundary is too narrow or that responsibilities are misplaced.
Document what the collaborator may do and test the observable outcome. Avoid tests that merely prove a private field is accessible. Test validation, state preservation and public behavior instead. When a new friend is proposed, ask whether a narrow public operation, a value returned by copy or a composed helper could satisfy the need without exposing representation. Friendship remains appropriate when its specific cooperative role is clearer than those alternatives.
Official references
C++ Friend Functions and Access Design Examples
Each example shows the code, the output it produces and what each part does.
A hidden friend compares private identity
The complete program compares two batches by their private lot ID. Quantity is deliberately excluded from the identity rule, because the operation asks whether the batches belong to the same lot.
The operation is a free function found with Batch arguments. It does not expose a writable lot identifier. The quantity member remains private even though this particular friend chooses not to inspect it.
#include <iostream>
#include <stdexcept>
class Batch {
int lot_id_;
int quantity_;
public:
Batch(int lot_id, int quantity)
: lot_id_(lot_id), quantity_(quantity) {
if (lot_id <= 0 || quantity < 0)
throw std::invalid_argument("invalid batch");
}
int quantity() const noexcept { return quantity_; }
friend bool same_lot(const Batch& left,
const Batch& right) noexcept {
return left.lot_id_ == right.lot_id_;
}
};
int main() {
Batch first(7, 10);
Batch second(7, 3);
Batch third(8, 10);
std::cout << std::boolalpha;
std::cout << same_lot(first, second) << '\n';
std::cout << same_lot(first, third) << '\n';
}true
falseC++ Friend Functions and Access Design in Real Projects
Worked exercise: reserve stock through a collaborator
The task is to let a reservation service subtract a positive amount only when sufficient stock exists. The stock count remains private, and no general public setter is added. The class grants the service access under a documented collaboration. This complete example remains single-threaded; friendship supplies no synchronization.
#include <iostream>
#include <stdexcept>
class ReservationService;
class Stock {
int quantity_;
friend class ReservationService;
public:
explicit Stock(int quantity) : quantity_(quantity) {
if (quantity < 0)
throw std::invalid_argument("negative stock");
}
int remaining() const noexcept { return quantity_; }
};
class ReservationService {
public:
bool reserve(Stock& stock, int requested) const {
if (requested <= 0)
throw std::invalid_argument("nonpositive request");
if (requested > stock.quantity_)
return false;
stock.quantity_ -= requested;
return true;
}
};
int main() {
Stock stock(5);
ReservationService reservations;
std::cout << std::boolalpha;
std::cout << reservations.reserve(stock, 3) << '\n';
std::cout << reservations.reserve(stock, 4) << '\n';
std::cout << "Remaining: " << stock.remaining() << '\n';
}true
false
Remaining: 2The rejected second operation leaves stock unchanged. For concurrent reservations, the complete check-and-subtract transition needs an appropriate synchronization or database contract, independently of the access grant.
C++ Friend Functions and Access Design FAQ
Is a friend function a class member?
No. It is a nonmember with an explicit access grant. It has no implicit this pointer and receives objects as ordinary arguments. Defining it inside the class can support hidden-friend lookup, but does not make object-dot invocation its normal call form. This distinction explains why the example calls same_lot with two Batch arguments rather than as a Batch member.
Does friendship pass through inheritance?
Not automatically. A derived collaborator does not inherit the access grant made to its base, and friendship is not transitive through other friendships. Each permission is specific. If a new operation needs private access, review and declare that relationship intentionally. Do not assume inheritance or a chain of collaborators silently expands the granting class's trust boundary.
Does a friend class break encapsulation?
It can preserve a clear cooperative interface when the grant is deliberate, but it gives broad privileged access to that collaborator. The friend implementation must maintain invariants and avoid leaking representation. A narrow function grant can be preferable when only one operation needs access. Encapsulation is about controlled responsibility, so evaluate the actual relationship rather than the keyword alone.
Why use a hidden friend instead of a public getter?
A type-specific nonmember operation can inspect only the representation it needs without adding a general exposure point for every caller. Argument-dependent lookup keeps it associated with the type. A public getter may still be appropriate when observation is part of the public contract. Choose the design from responsibilities and lifetime needs, not simply from the shortest syntax.
C++ Friend Functions and Access Design Exercises
Answer each one and check it instantly. If you get stuck, open the hint before the answer.
A friend reservation operation rejects insufficient stock. What should its test verify?
C++ Friend Functions and Access Design Quiz
2 questions to check what you learned.
Which statement about a friend function is correct?
- It automatically has a this pointer.
- It makes all private fields public to everyone.
- It can be invoked only through an object of the granting class.
- It remains a nonmember with granted private access.
Warehouse grants Auditor friendship, and Auditor grants Helper friendship. What follows?
- Helper does not automatically gain Warehouse private access.
- Warehouse automatically gains Auditor's private access in return.
- Warehouse can automatically access every Auditor field.
- Friendship propagates through every dependency.