19. Inheritance

Advanced perspective: every inheritance edge makes a promise to somebody

Public inheritance is justified by substitutability, not by the number of lines it reuses

Inheritance can reuse implementation, but public inheritance declares something more important: a derived object may be treated as an object of its public base type. That conversion is useful only if the derived type continues to honour the expectations attached to the base interface. Similar names, shared members and a tidy diagram do not establish that relationship.

Before drawing an arrow from Player to Entity, identify the caller who will use an Entity and the promises that caller relies upon. Can every proposed derived object satisfy every permitted base operation? Does it preserve the meaning of results, failures and state changes? If the caller must discover the derived type before it can use the object correctly, the base has not provided the advertised abstraction.

A derived object contains a base subobject

#include <iostream>

class Entity {
public:
    explicit Entity(int identifier) : identifier_{identifier} {}

    int identifier() const {
        return identifier_;
    }

private:
    int identifier_;
};

class Player : public Entity {
public:
    Player(int identifier, int score) : Entity{identifier}, score_{score} {}

    int score() const {
        return score_;
    }

private:
    int score_;
};

void print_identity(const Entity& entity) {
    std::cout << entity.identifier() << '\n';
}

int main() {
    const Player player{7, 120};
    print_identity(player);
    std::cout << player.score() << '\n';
}

The Player object is one complete object containing an Entity base subobject and its own score_ member. The Player constructor supplies 7 to the base constructor and 120 to the member initialiser. Base construction completes before derived members and before the derived constructor body. The complete object is therefore built from an established base part outward.

When print_identity(player) binds its const Entity&, the reference designates the base subobject within the existing player. It does not create a separate copied entity. The non-virtual identifier() operation is available through that base interface and prints 7. Back in main, the player interface prints its score, 120.

Destruction follows the reverse structural order. The derived part is destroyed before its base subobject. This lets derived cleanup use an existing base part and ensures that the base does not disappear while derived destruction is still under way. It also explains why construction and destruction are not ordinary moments for virtual dispatch to a not-yet-constructed or already-destroyed derived part.

Write the base contract before testing a derived type

Substitutability is sometimes reduced to the phrase "is a" and left there. The useful work begins when the base contract is stated. A derived override must accept calls permitted by the base, preserve the base's promised results and invariants, and avoid introducing surprising obligations that a base caller could not know. The derived type may offer additional operations or stronger guarantees, but it cannot make a previously valid base use invalid without changing the abstraction.

This does not require every base to publish a formal contract language. It does require enough behavioural precision that tests can exercise a derived object through the base interface. If the only test calls derived-specific functions, it has not tested substitution.

Object slicing is a value operation, not partial polymorphism

Initialising a separate base object from a derived object copies the base portion into a new base value. The derived members are not part of that destination object. This is object slicing. It can be deliberate when the program genuinely wants an independent base value, but it cannot preserve the derived identity or behaviour expected from runtime polymorphism.

A base reference or pointer can preserve access to the base subobject within the complete derived object. An owning smart pointer to the base can preserve dynamic identity when the design allocates objects polymorphically. These choices answer different ownership questions; replacing every sliced value with a raw pointer would merely exchange one problem for another.

Destruction policy follows permitted ownership

If a Shape* designates a separately allocated Circle and callers are allowed to execute delete shape;, destruction must reach the complete Circle. A public virtual destructor in the base expresses that policy. Without it, deletion through that base pointer does not correctly destroy the derived object and has undefined behaviour.

That does not mean every base class mechanically needs a public virtual destructor. A base used only as a non-owning interface may prohibit deletion through the base, for example with a protected non-virtual destructor. A non-polymorphic base-subobject relationship may never involve virtual calls or base-pointer ownership at all. Ask who may destroy the object and through which static type. The answer determines the destructor policy.

Hiding, overriding and overloading are different events

A derived declaration with the same name as base functions can hide the base overload set during lookup, even when its parameter list differs. That is name hiding. Overriding requires a matching virtual function contract, including relevant qualifiers. Overloading supplies multiple declarations under one name for different parameter forms. Treating all three as "the derived version" makes compiler errors look arbitrary.

Use override whenever an override is intended. If the parameter type, const qualifier or reference qualifier fails to match, the compiler rejects the declaration instead of silently creating a different function. A using Base::draw; declaration can deliberately reintroduce hidden base overloads into the derived scope. These keywords do not design the hierarchy, but they make the chosen design more checkable.

final has a narrower meaning. On a virtual function it prevents further overrides; on a class it prevents further derivation. It is not a decorative synonym for complete, safe or non-virtual.

Composition avoids promises that are not required

A car uses an engine as part of its responsibility. Making the car publicly inherit from the engine would expose engine operations as car operations and invite substitution where none is intended. Composition says only that the car contains or collaborates with an engine. It allows the car to restrict, coordinate or replace that implementation without claiming to satisfy the engine interface itself.

Private inheritance can also reuse implementation while withholding the public base relationship, and empty bases have specialised layout uses. Yet composition usually makes ownership and delegation more visible. Choose inheritance when access to protected members, virtual customisation or another language property is part of the design, not because delegation requires a few explicit functions.

Keep the customisation surface smaller than the public story

Every protected data member and virtual hook becomes part of the contract offered to derived authors. A base change can therefore break code outside the base's ordinary public callers. The Non-Virtual Interface pattern reduces that surface: a public non-virtual operation enforces ordering and invariants, while narrow virtual steps supply permitted variation. It does not remove the need to document those steps, but it prevents an override from replacing the entire public contract by accident.

Multiple inheritance needs the same restraint. Combining independent interface roles can be coherent. Combining stateful bases that share a common base can create multiple base subobjects and ambiguous access. Virtual inheritance can arrange one shared virtual base, whose initialisation is ultimately the responsibility of the most-derived class. That mechanism solves a particular object-model problem; it does not prove that the resulting hierarchy is understandable.

Performance follows the required substitution model

Virtual dispatch commonly involves an indirect call and can inhibit some optimisations. Templates and other static techniques can expose concrete types to the compiler. Neither fact decides the architecture in isolation. Runtime-loaded implementations, binary interfaces or heterogeneous owning collections may require runtime substitution. A closed set of operations in performance-critical code may suit compile-time variation.

Measure the real call path before replacing a clear interface with templates or CRTP. The dispatch cost may be material, hidden by larger work, or outweighed by code size and build complexity. "Zero overhead" is a claim about a particular generated program and workload, not a magic property of angle brackets.

Transfer task: test the promise before accepting the hierarchy

A base Counter promises that every successful call to increment() increases value() by exactly one. Someone proposes BoundedCounter : public Counter, but at its limit the override silently leaves the value unchanged while reporting success. Write the observation a base caller would make and explain precisely which promise is broken.

Redesign the relationship in two ways. First, change the base contract so reaching a limit is an explicit result that every implementation may report. Second, keep the original Counter contract and build a bounded component by composition that refuses the request before delegating. For each design, state who benefits from the common interface, whether base-pointer deletion is allowed, and which tests must run through the base view. The fewer lines version does not win automatically. The version whose promises are true does.

Counter& counter = bounded;
const auto before = counter.value();
const bool reported_success = counter.increment();
const auto after = counter.value();

// At the bound:
// reported_success == true
// after == before

#include <cstdint>

enum class IncrementResult {
    incremented,
    at_limit
};

class Counter {
public:
    virtual ~Counter() = default;

    [[nodiscard]] virtual IncrementResult increment() = 0;
    [[nodiscard]] virtual std::uint64_t value() const noexcept = 0;
};

#include <cstdint>
#include <limits>
#include <stdexcept>

class ExactCounter final {
public:
    explicit ExactCounter(std::uint64_t initial = 0) noexcept
        : value_{initial} {}

    void increment()
    {
        if (value_ == std::numeric_limits<std::uint64_t>::max()) {
            throw std::overflow_error{"counter cannot be incremented"};
        }
        ++value_;
    }

    [[nodiscard]] std::uint64_t value() const noexcept {
        return value_;
    }

private:
    std::uint64_t value_ = 0;
};

class BoundedCounter {
public:
    BoundedCounter(std::uint64_t initial, std::uint64_t limit);

    [[nodiscard]] bool try_increment()
    {
        if (counter_.value() == limit_) {
            return false;
        }
        counter_.increment();
        return true;
    }

    [[nodiscard]] std::uint64_t value() const noexcept {
        return counter_.value();
    }

private:
    ExactCounter counter_;
    std::uint64_t limit_ = 0;
};

Inheritance changes object layout, construction, lookup, destruction and the obligations visible to callers. Use it when those changes express a real substitutable relationship. Code reuse is welcome after that decision; it is not the decision.