4.4 Inheritance, Polymorphism and Virtual Tables

Polymorphism allows us to write generic interfaces where base class pointers invoke derived class overrides at runtime. In languages like Java, all class methods are polymorphic by default. In C++, polymorphism is opt in (using the virtual keyword) because runtime dynamic dispatch adds physical memory and execution overhead.

Let's look at how polymorphism is implemented in memory and the critical rule of virtual destructors.

Most mainstream C++ implementations resolve virtual calls with a hidden virtual table (vtable) and a per-object pointer (vptr) to it. The C++ standard specifies the observable virtual-dispatch behavior, not this representation or where any hidden field appears in object layout.

Use a vtable diagram as a common implementation model, not a portable binary-layout contract. ABI boundaries, compiler options, and inheritance shape can all affect the generated representation.

When you call a virtual function, the CPU cannot jump directly to the instruction block. Instead, it must execute three separate steps:

1. Dereference the object's vptr to find the address of the vtable.

1. Index into the vtable to locate the target function pointer.

1. Perform an indirect call to that address.

This vtable lookup adds latency and prevents the compiler from performing inline optimizations. More importantly, it destroys CPU Branch Prediction.

A virtual call can inhibit inlining and may be harder for branch prediction when dynamic targets vary. It is often fine outside a measured hot loop, and even in hot code the right choice depends on data layout, call distribution, and readability. Replace polymorphism only after profiling identifies it as material.

• The Switchboard Metaphor: Calling a standard function is like dialing a direct number. Calling a virtual function is like calling a 1950s switchboard operator. You have to wait for the operator to look up the name in a directory book (vtable) and plug the wire in, adding connection delays to your execution path.

Deleting a derived object through a base pointer whose destructor is not virtual is undefined behavior. A common symptom is skipped derived cleanup, but no particular outcome is guaranteed:

#include <iostream>

class Base {
public:
    Base() {}
    // DANGER: Non virtual destructor!
    ~Base() {
        std::cout << "Base destructor called.\n";
    }
};

class Derived : public Base {
    int* heapBuffer;
public:
    Derived() : heapBuffer{new int[1000]} {}
    ~Derived() {
        delete[] heapBuffer; // Will NOT be called if deleted via Base*!
        std::cout << "Derived destructor called (Buffer freed).\n";
    }
};

int main() {
    Base* ptr{new Derived()};
    delete ptr; // Only prints "Base destructor called." heapBuffer leaks!
    return 0;
}

To fix this hazard, always declare destructors as virtual in any class you expect developers to inherit from. This guarantees the destructor chain runs in the correct order: from the derived class up to the base class.