Runtime polymorphism in C++ - Deep Dive

Overview - Runtime polymorphism

What is it?

Runtime polymorphism is a way in C++ where a program decides which function to call while it is running, not when it is compiled. It allows objects of different classes related by inheritance to be treated through a common interface, but behave differently depending on their actual type. This is done using virtual functions and pointers or references to base classes. It helps write flexible and reusable code that can work with new types without changing existing code.

Why it matters

Without runtime polymorphism, programs would have to know exactly which type of object they are working with at compile time, making them rigid and hard to extend. It solves the problem of needing different behaviors for different types while using a single interface. This makes software easier to maintain and expand, like adding new features without breaking old ones. Imagine a music player that can play many formats without rewriting the whole player for each format.

Where it fits

Before learning runtime polymorphism, you should understand basic C++ classes, inheritance, and function overriding. After mastering runtime polymorphism, you can explore advanced topics like design patterns (e.g., Strategy, Observer), templates, and compile-time polymorphism with templates.

Mental Model

Core Idea

Runtime polymorphism lets a program decide which version of a function to run based on the actual object type during execution, enabling flexible and dynamic behavior.

Think of it like...

It's like a universal remote control that can operate different devices (TV, DVD player, sound system) by pressing the same button, but the device decides what action to perform based on what it is.

Base Class
  │
  ├─ Derived Class A (overrides virtual function)
  └─ Derived Class B (overrides virtual function)

At runtime:
Pointer to Base Class → points to Derived A or Derived B → calls the correct overridden function

Build-Up - 7 Steps

1

Foundation

Understanding basic inheritance

Concept: Inheritance allows one class to use properties and behaviors of another class.

In C++, a class can inherit from another class, gaining its members. For example: class Animal { public: void speak() { std::cout << "Animal sound" << std::endl; } }; class Dog : public Animal { public: void speak() { std::cout << "Bark" << std::endl; } };

Result

Dog objects have the speak() function, but it currently calls Animal's version if accessed through an Animal pointer.

Understanding inheritance is key because runtime polymorphism builds on the idea that derived classes can change or extend base class behavior.

2

Foundation

Function overriding basics

Concept: Derived classes can provide their own version of a function defined in the base class.

Continuing from the previous example, Dog overrides speak(): Dog dog; dog.speak(); // Calls Dog's speak, prints "Bark" Animal* animalPtr = &dog; animalPtr->speak(); // Calls Animal's speak, prints "Animal sound"

Result

Calling speak() on a Dog object directly uses Dog's version, but calling through a base class pointer uses the base version.

Overriding lets derived classes customize behavior, but without runtime polymorphism, base pointers call base functions, limiting flexibility.

3

Intermediate

Introducing virtual functions

🤔Before reading on: do you think adding 'virtual' to a base function changes which function a base pointer calls? Commit to yes or no.

Concept: Declaring a base class function as virtual tells C++ to decide at runtime which function to call based on the actual object type.

Modify the base class: class Animal { public: virtual void speak() { std::cout << "Animal sound" << std::endl; } }; class Dog : public Animal { public: void speak() override { std::cout << "Bark" << std::endl; } }; Now: Animal* animalPtr = new Dog(); animalPtr->speak(); // Calls Dog's speak, prints "Bark"

Result

The program calls the derived class's speak() even when using a base class pointer.

Virtual functions enable dynamic dispatch, the core mechanism behind runtime polymorphism, allowing flexible and correct behavior.

4

Intermediate

Using base class pointers and references

🤔Before reading on: do you think runtime polymorphism works with references as well as pointers? Commit to yes or no.

Concept: Runtime polymorphism works when using pointers or references to base classes to refer to derived objects.

Example with reference: void makeSpeak(Animal& animal) { animal.speak(); } Dog dog; makeSpeak(dog); // Calls Dog's speak, prints "Bark"

Result

References to base classes also call the correct overridden function at runtime.

Knowing that both pointers and references support runtime polymorphism helps write flexible interfaces and APIs.

5

Intermediate

Virtual destructors importance

🤔Before reading on: do you think destructors should be virtual in base classes? Commit to yes or no.

Concept: If a base class has virtual functions, its destructor should also be virtual to ensure proper cleanup of derived objects.

Without virtual destructor: Animal* animalPtr = new Dog(); delete animalPtr; // Only Animal destructor called, Dog destructor skipped With virtual destructor: class Animal { public: virtual ~Animal() {} }; Now delete calls both destructors correctly.

Result

Proper resource cleanup happens when deleting derived objects through base pointers.

Understanding virtual destructors prevents subtle bugs and memory leaks in polymorphic class hierarchies.

6

Advanced

How vtable enables runtime polymorphism

🤔Before reading on: do you think C++ uses a table to find the right function at runtime? Commit to yes or no.

Concept: C++ uses a hidden table called vtable to map virtual functions to their correct implementations for each class.

Each class with virtual functions has a vtable storing pointers to its virtual functions. Each object has a pointer to its class's vtable. When calling a virtual function, the program looks up the function address in the vtable and calls it.

Result

The program dynamically dispatches the correct function based on the object's actual type.

Knowing about vtables explains how runtime polymorphism works efficiently behind the scenes.

7

Expert

Performance and pitfalls of runtime polymorphism

🤔Before reading on: do you think virtual function calls are as fast as normal calls? Commit to yes or no.

Concept: Virtual calls have a small runtime cost due to indirection, and misuse can cause bugs like slicing or unexpected behavior.

Virtual calls require an extra pointer lookup, making them slightly slower than direct calls. Object slicing happens when a derived object is copied into a base object, losing derived parts. Also, forgetting virtual destructors causes resource leaks.

Result

Understanding these helps write efficient and correct polymorphic code.

Recognizing runtime costs and common mistakes helps experts write safer and faster polymorphic programs.

Under the Hood

At runtime, each polymorphic object contains a hidden pointer to a vtable, a table of function pointers for virtual functions. When a virtual function is called through a base pointer or reference, the program uses the object's vtable pointer to find the correct function address and calls it. This lookup happens dynamically, enabling the program to choose the right function based on the actual object type, not the pointer type.

Why designed this way?

This design balances flexibility and performance. Early C++ versions needed a way to support dynamic behavior without losing speed for non-virtual calls. The vtable approach allows fast indirect calls with minimal overhead. Alternatives like name-based lookup or dynamic typing were slower or less type-safe. The vtable method also fits well with static typing and compile-time checks.

Object Memory Layout:
┌───────────────┐
│ vptr (points to vtable) │
├───────────────┤
│ data members  │
└───────────────┘

Vtable for Derived Class:
┌─────────────────────────┐
│ &Derived::speak         │
│ &Derived::otherVirtual  │
└─────────────────────────┘

Call flow:
BasePtr -> Object -> vptr -> vtable -> function pointer -> call function

Myth Busters - 4 Common Misconceptions

Quick: Does declaring a function virtual in the base class automatically make all derived class functions virtual? Commit to yes or no.

Common Belief: If a base class function is virtual, all overriding functions in derived classes are automatically virtual without explicit keyword.

Reality: In C++, once a function is virtual in the base class, overriding functions are virtual even if not marked, but it's good style to mark them with 'override' for clarity.

Why it matters: Not understanding this can lead to confusion about which functions are virtual and cause maintenance issues or bugs.

Quick: Can you call a virtual function from a constructor and expect polymorphic behavior? Commit to yes or no.

Common Belief: Virtual functions called inside constructors or destructors behave polymorphically and call derived overrides.

Reality: During construction or destruction, virtual calls use the class's own version, not derived overrides, because derived parts are not yet or no longer constructed.

Why it matters: Expecting polymorphic behavior in constructors leads to bugs and unexpected results.

Quick: Does runtime polymorphism work with objects, not just pointers or references? Commit to yes or no.

Common Belief: You can achieve runtime polymorphism by assigning derived objects to base class objects directly.

Reality: Assigning derived objects to base objects causes slicing, losing derived parts and disabling polymorphism. Runtime polymorphism requires pointers or references.

Why it matters: Misusing objects instead of pointers causes silent bugs and loss of dynamic behavior.

Quick: Is runtime polymorphism free of performance cost? Commit to yes or no.

Common Belief: Virtual function calls are as fast as normal function calls.

Reality: Virtual calls have a small overhead due to vtable lookup and indirect call, making them slower than direct calls.

Why it matters: Ignoring this can cause performance issues in critical code sections.

Expert Zone

1

The 'override' keyword not only documents intent but also lets the compiler catch mismatches, preventing subtle bugs.

2

Multiple inheritance with virtual functions can cause complex vtable layouts and requires careful design to avoid ambiguity.

3

The order of constructor and destructor calls affects virtual dispatch, so calling virtual functions in these can lead to surprising behavior.

When NOT to use

Avoid runtime polymorphism when performance is critical and the set of types is fixed; prefer compile-time polymorphism with templates. Also, avoid it when object slicing or ownership issues are likely; use smart pointers or alternative designs like variant or std::function.

Production Patterns

Common patterns include using runtime polymorphism for plugin systems, GUI event handling, and strategy pattern implementations. It enables writing code that works with abstract interfaces while concrete implementations can be swapped or extended without recompiling.

Connections

Compile-time polymorphism (Templates)

Alternative polymorphism approach using templates instead of virtual functions.

Understanding runtime polymorphism clarifies why templates offer faster but less flexible polymorphism, helping choose the right tool.

Dynamic dispatch in other languages

Runtime polymorphism in C++ is a form of dynamic dispatch, similar to method calls in languages like Java or Python.

Knowing C++ runtime polymorphism helps understand how other languages implement method overriding and dynamic behavior.

Biology: Animal classification

Inheritance and polymorphism mirror biological classification where animals share traits but behave differently.

Seeing polymorphism as animals responding differently to the same stimulus helps grasp why code uses common interfaces with different behaviors.

Common Pitfalls

#1 Calling virtual functions inside constructors expecting polymorphic behavior.

Wrong approach:

class Base {
public:
Base() { speak(); }
virtual void speak() { std::cout << "Base" << std::endl; }
};

class Derived : public Base {
public:
void speak() override { std::cout << "Derived" << std::endl; }
};

Derived d; // Prints "Base", not "Derived"

Correct approach:

Avoid calling virtual functions in constructors or use separate initialization functions called after construction.

Root cause:

During construction, the object is treated as the base class, so virtual calls do not dispatch to derived overrides.

#2 Deleting derived objects through base pointers without virtual destructor causing resource leaks.

Wrong approach:

class Base {
public:
~Base() { std::cout << "Base destructor" << std::endl; }
};

class Derived : public Base {
public:
~Derived() { std::cout << "Derived destructor" << std::endl; }
};

Base* ptr = new Derived();
delete ptr; // Only Base destructor called

Correct approach:

class Base {
public:
virtual ~Base() { std::cout << "Base destructor" << std::endl; }
};

Now delete ptr calls both destructors correctly.

Root cause:

Without virtual destructor, base class destructor is called directly, skipping derived cleanup.

#3 Assigning derived objects to base objects causing slicing and losing polymorphism.

Wrong approach:

Derived d;
Base b = d; // Object slicing
b.speak(); // Calls Base::speak, not Derived::speak

Correct approach:

Use pointers or references:
Derived d;
Base& b = d;
b.speak(); // Calls Derived::speak

Root cause:

Copying derived object into base object slices off derived parts, disabling polymorphism.

Key Takeaways

Runtime polymorphism lets programs decide which function to call based on the actual object type during execution, enabling flexible and reusable code.

It requires virtual functions and using pointers or references to base classes to work correctly.

Virtual destructors are essential to avoid resource leaks when deleting derived objects through base pointers.

Behind the scenes, C++ uses vtables and vptrs to implement runtime polymorphism efficiently.

Misusing runtime polymorphism, like calling virtual functions in constructors or object slicing, leads to bugs and unexpected behavior.