Compile-Time vs. Run-Time Polymorphism

The Problem: How to Call the Right Function?

Let's start with a classic object-oriented scenario. You have a base class pointer that could be pointing to objects of different derived types.

class Animal {
public:
    virtual void speak() { /* default sound */ }
};

class Dog : public Animal {
public:
    void speak() override { /* woof */ }
};

class Cat : public Animal {
public:
    void speak() override { /* meow */ }
};

void make_sound(Animal* animal_ptr) {
    animal_ptr->speak(); // Which speak() gets called? Dog's or Cat's?
}

The compiler, looking only at the type Animal*, cannot know the actual type of the object at compile time. The decision must be delayed until the program is running. This is called dynamic dispatch. How does the CPU execute this?

Runtime Polymorphism: The V-Table Mechanism

The "magic" of virtual functions is not magic at all; it's a well-defined mechanical pattern implemented by the compiler. It involves two key components: the virtual pointer (vptr) and the virtual table (vtable).

• V-Table (Virtual Method Table): For each class that has at least one virtual function, the compiler generates a static array of function pointers. This array is the vtable. There is only one vtable per class.
• V-Pointer (Virtual Pointer): When an object of such a class is created, the compiler secretly inserts a hidden pointer into the object's memory layout. This pointer, the vptr, points to the vtable for that class. Every object instance has its own vptr.

When you make a virtual function call like animal_ptr->speak(), the generated machine code performs these steps:

1. Dereference the animal_ptr to get to the object's data.
2. Read the hidden vptr from the object's memory (usually at the very beginning).
3. Follow the vptr to the class's vtable in static memory.
4. Look up the correct function pointer in the vtable using a fixed offset (e.g., speak() might be the first entry).
5. Call the function at that address.

This mechanism is a standard design pattern. In fact, you could implement it yourself in C using structs and function pointers, which gives you a first-principles understanding of what the C++ compiler does for you automatically.

As the video explained, the costs of dynamic dispatch are significant:

1. Memory Overhead: Each object carries an extra vptr (typically 8 bytes on a 64-bit system).
2. Runtime Overhead (Indirection): Each call involves at least two extra memory reads (one to get the vptr, one to get the function address from the vtable). This can lead to cache misses if the vtable isn't in the CPU's cache.
3. Optimization Barrier (No Inlining): This is often the biggest cost. Because the compiler doesn't know the exact function to be called, it cannot perform its most powerful optimization: inlining. It must generate a full function call, which involves setting up a stack frame, jumping, and returning.

Compile-Time Polymorphism: Static Dispatch with Templates

Now, let's contrast this with the template-based polymorphism we've been studying.

template<typename T>
void make_sound_static(T& animal) {
    animal.speak(); // Resolved at COMPILE time
}

Dog my_dog;
make_sound_static(my_dog); // Compiler generates a version of make_sound_static for Dog

Cat my_cat;
make_sound_static(my_cat); // Compiler generates a separate version for Cat

Here, the process is entirely different:

1. When the compiler sees make_sound_static(my_dog), it knows the type T is Dog.
2. It instantiates a specific version of the function: void make_sound_static(Dog& animal) { animal.speak(); }.
3. The call animal.speak() is resolved directly to Dog::speak. This is static binding.
4. Because the call target is known, the compiler is free to inline the Dog::speak() function, potentially replacing the call with the function's body directly. No vptr, no vtable, no runtime lookup.

This is fundamentally more efficient at the machine level. To see just how different the generated code is, we'll examine an article that benchmarks virtual calls against a form of static polymorphism called the Curiously Recurring Template Pattern (CRTP).

A Head-to-Head Comparison: Choosing the Right Tool

It's clear that static polymorphism is faster. So why would anyone use virtual functions? Because performance isn't the only factor. The choice depends on the problem you're solving.

The following video explores this trade-off from a modern C++ perspective, arguing that many traditional uses of virtual functions can now be replaced with template-based designs for better performance and type safety.

Conclusion

You have now seen the two faces of polymorphism in C++. They are not competing features, but powerful tools designed for different scenarios.

Key Takeaways:

• Runtime Polymorphism (virtual functions) achieves flexibility through dynamic binding. It uses a vptr and vtable to look up the correct function at runtime. Its main cost is performance overhead and a reliance on inheritance. It's essential when you need to handle types that are unknown at compile time.
• Compile-Time Polymorphism (templates) achieves high performance through static binding. The compiler generates specialized code for each type, enabling optimizations like inlining. Its main cost is potential code bloat and the requirement that all types be known at compile time. It's the foundation of generic programming in C++, like the STL.

Choosing between them is a core architectural decision. As a systems developer aiming for high performance, you will often lean towards compile-time solutions, but you must recognize when the runtime flexibility offered by virtual functions is necessary.

What's Next?

We've now established the theoretical and practical differences between these two approaches. In the next module, we'll begin our exploration of the Standard Template Library (STL) internals. We'll start with std::vector, a perfect case study of compile-time polymorphism in action. You'll see how templates are used to create a generic, high-performance container, and we'll analyze its internal memory management strategy, which is crucial for writing efficient and correct code.