21. Polymorphism

Advanced perspective: runtime selection is useful only when every selected behaviour keeps one promise

Virtual dispatch selects the final overrider; the interface must still make that behaviour correct

Runtime polymorphism lets one call site use a stable base interface while the complete object's dynamic type selects a virtual implementation. The static type of the expression tells the compiler which operations may be requested. The dynamic type identifies the complete object present during execution. For a virtual call, the final overrider supplies the implementation selected for that object.

Calling this the "correct method" hides an important design obligation. C++ can select Circle::area() for a circle. It cannot decide whether that function honours the meaning, units, valid inputs and failure behaviour promised by Shape::area(). Dispatch solves runtime selection. A common behavioural contract makes the selected result usable.

Trace static type, dynamic type, final overrider and owner together

#include <iostream>
#include <memory>
#include <numbers>
#include <vector>

class Shape {
public:
    virtual ~Shape() = default;
    virtual double area() const = 0;
};

class Rectangle final : public Shape {
public:
    Rectangle(double width, double height) : width_{width}, height_{height} {}

    double area() const override {
        return width_ * height_;
    }

private:
    double width_;
    double height_;
};

class Circle final : public Shape {
public:
    explicit Circle(double radius) : radius_{radius} {}

    double area() const override {
        return std::numbers::pi * radius_ * radius_;
    }

private:
    double radius_;
};

int main() {
    std::vector<std::unique_ptr<Shape>> shapes;
    shapes.push_back(std::make_unique<Rectangle>(3.0, 4.0));
    shapes.push_back(std::make_unique<Circle>(2.0));

    for (const auto& shape : shapes) {
        std::cout << shape->area() << '\n';
    }
}

The vector owns two separately allocated complete objects through unique_ptr<Shape>. The first pointer owns a Rectangle; the second owns a Circle. Inside the loop, the expression shape is a reference to a unique_ptr<Shape>, and shape-> reaches each object through the base interface.

For the first call, the dynamic type is Rectangle and the final overrider is Rectangle::area(), giving 3 times 4, or 12. For the second, the dynamic type is Circle and Circle::area() gives 4 times pi. Both calls have the same source spelling. Their selected implementations differ because their complete objects differ.

The override specifier asks the compiler to verify that each derived declaration actually overrides a base virtual. A missing const, different parameter or incompatible qualifier then becomes a diagnostic instead of silently introducing a separate function. final on these derived classes states that no further class may derive from them. Neither keyword proves the area formula; tests still must.

Ownership is not an optional footnote to dispatch

A reference or pointer preserves access to the complete derived object rather than creating a sliced base value. It does not say who owns that object. In this example, each unique_ptr<Shape> owns exactly one allocation, the vector owns those smart pointers, and destruction follows the vector's lifetime. That ownership chain is part of why the loop is safe.

The base destructor is virtual because deletion occurs through a base-typed owning pointer. When a unique_ptr<Shape> releases a Circle, destruction must reach the complete circle before its Shape base part. The smart pointer automates the delete expression; the virtual destructor makes base-directed deletion correct for the dynamic type. One mechanism cannot substitute for the other.

This abstract Shape cannot itself be stored as concrete values because its pure virtual operation leaves it abstract. Even for a concrete base, a vector of base values would contain base objects, not a heterogeneous set of complete derived objects. Smart pointers are not selected merely because "polymorphism uses pointers"; they are selected here because the collection owns objects whose concrete sizes and types differ at runtime.

Know exactly when virtual dispatch is suppressed or limited

The default-argument case is especially instructive. Dynamic dispatch does not retroactively make every part of the call dynamic. If callers omit an argument through a base interface, the base declaration supplies the default even when a derived body executes. A stable virtual interface should avoid making correctness depend on different defaults in different overrides.

Abstract means incomplete for direct objects, not absent behaviour

A pure virtual function makes the class abstract, so the program cannot create a direct object of that class. It requires a final overrider in any concrete derived object that is instantiated. The base still supplies state, non-virtual operations and, in some designs, even a definition for a pure virtual function that can be called through qualification. "Pure" describes the interface requirement; it does not mean the base contains nothing.

Keep the base contract small enough that every implementation can honour it without type tests or invented failure modes. A large interface often forces derived classes to implement operations that make no sense for them. Empty stubs and exceptions added solely because the base demanded the function are evidence that the abstraction may be too broad.

Downcasts should be evidence, not the default extension mechanism

dynamic_cast can test or recover a derived type through a polymorphic base. A pointer cast reports failure with nullptr; a reference cast reports failure by throwing std::bad_cast. The facility is legitimate when an operation genuinely applies to one optional capability or when crossing an external interface.

A repeated chain of downcasts often says something else: callers know all concrete types and the base lacks the behaviour they actually need. Adding a virtual operation, separating capabilities into smaller interfaces, using a visitor or choosing a closed-set representation may express the design more honestly. The cast is not automatically wrong. It is a request to explain why runtime type discovery belongs at that caller.

Implementation folklore is not the language contract

Implementations commonly realise virtual dispatch with virtual tables and hidden per-object information. The language specifies observable call behaviour rather than requiring one exact layout. Teach the common mechanism when it helps explain cost or debugging, but do not turn an implementation model into a portable memory-layout promise.

A virtual call may add an indirect branch and can inhibit inlining where the compiler cannot determine the target. In a heterogeneous owning collection, separate allocations and pointer chasing may affect locality as much as or more than the dispatch itself. The virtual function's own work may dominate both. Measure the complete hot path with representative objects and an optimised build before redesigning the architecture around a presumed single-call cost.

Templates, variants, function objects and type erasure offer other forms of variation. Static polymorphism can expose concrete types to optimisation but may increase code generation, compile time and coupling. A variant suits a closed set of alternatives and makes visitation explicit. Virtual dispatch suits an open family behind a stable runtime interface. Select from the variation requirement first; performance evidence then refines the choice.

Transfer task: make one call site earn its uniformity

Design an abstract Effect with apply(double input) const. The base contract says that a finite input must produce a finite result or report failure explicitly; it must not modify the effect. Create three proposed implementations: a fixed addition, a multiplication and a division by a configured value. Decide what construction must reject, what the virtual operation promises and how failure is represented without weakening the base for one derived type.

Place mixed effects in an owning collection and trace one input through them. For each call, record static type, dynamic type, final overrider, result and owner. Then compare a virtual hierarchy with a closed variant of the same three effects. Which design permits new effect types without modifying the caller? Which makes the complete set visible to the compiler? Do not choose by repeating "virtual is flexible" or "variant is faster". State the extension model and the measurement that would settle any material performance difference.

#include <cmath>
#include <memory>
#include <stdexcept>
#include <variant>
#include <vector>

enum class EffectError {
    non_finite_input,
    non_finite_result
};

using EffectResult = std::variant<double, EffectError>;

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

    [[nodiscard]] virtual EffectResult
    apply(double input) const = 0;
};

EffectResult checked_result(double value)
{
    if (!std::isfinite(value)) {
        return EffectError::non_finite_result;
    }
    return value;
}

class FixedAddition final : public Effect {
public:
    explicit FixedAddition(double amount) : amount_{amount}
    {
        if (!std::isfinite(amount_)) {
            throw std::invalid_argument{"addition must be finite"};
        }
    }

    EffectResult apply(double input) const override
    {
        if (!std::isfinite(input)) {
            return EffectError::non_finite_input;
        }
        return checked_result(input + amount_);
    }

private:
    double amount_;
};

class Multiplication final : public Effect {
public:
    explicit Multiplication(double factor) : factor_{factor}
    {
        if (!std::isfinite(factor_)) {
            throw std::invalid_argument{"factor must be finite"};
        }
    }

    EffectResult apply(double input) const override
    {
        if (!std::isfinite(input)) {
            return EffectError::non_finite_input;
        }
        return checked_result(input * factor_);
    }

private:
    double factor_;
};

class Division final : public Effect {
public:
    explicit Division(double divisor) : divisor_{divisor}
    {
        if (!std::isfinite(divisor_) || divisor_ == 0.0) {
            throw std::invalid_argument{"divisor must be finite and non-zero"};
        }
    }

    EffectResult apply(double input) const override
    {
        if (!std::isfinite(input)) {
            return EffectError::non_finite_input;
        }
        return checked_result(input / divisor_);
    }

private:
    double divisor_;
};

std::vector<std::unique_ptr<Effect>> effects;
effects.push_back(std::make_unique<FixedAddition>(2.0));
effects.push_back(std::make_unique<Multiplication>(3.0));
effects.push_back(std::make_unique<Division>(4.0));

Runtime polymorphism earns its place when one stable contract lets a caller remain ignorant of several genuine implementations. The dispatch mechanism chooses the body. The type design, ownership model and tests decide whether that body belongs there.