Understanding the Underlying Principles of Polymorphism in C++

Polymorphism is divided into compile-time polymorphism and runtime polymorphism. Can you explain this in detail?

Compile-time Polymorphism (Static Binding)

Compile-time polymorphism, also known as static binding or early binding, is when the function to be called is determined during the compilation phase.

Implementation Method: Mainly achieved through function overloading and templates.

Principle: The compiler will find and bind to the correct function version at compile time based on the function name, parameter types, and the number of parameters.

Characteristics: High efficiency, as there is no need to search at runtime.

Example: Function Overloading

#include <iostream>
void print(int i) {    std::cout << "Printing integer: " << i << std::endl;}
void print(double f) {    std::cout << "Printing double: " << f << std::endl;}
void print(const char* s) {    std::cout << "Printing string: " << s << std::endl;}
int main() {    print(10);        // Compile-time determines to call print(int)    print(3.14);      // Compile-time determines to call print(double)    print("Hello");   // Compile-time determines to call print(const char*)    return 0;}

Runtime Polymorphism (Dynamic Binding)

Runtime polymorphism, also known as dynamic binding or late binding, is when the function to be called can only be determined during the program execution phase.

Implementation Method: Mainly achieved through virtual functions (virtual) and base class pointers/references.

Principle: The compiler creates a virtual function table (vtable) for each class containing virtual functions at compile time. Each object will have a virtual function pointer (vptr) pointing to this table. At runtime, the program will use this vptr to find the correct function address and call it.

Characteristics: Offers flexibility and extensibility, but introduces additional performance overhead (searching the vtable).

Example: Virtual Functions

#include <iostream>
class Animal {public:    virtual void speak() { // virtual keyword is crucial        std::cout << "The animal is speaking..." << std::endl;    }};
class Dog : public Animal {public:    void speak() override {        std::cout << "Woof Woof!" << std::endl;    }};
class Cat : public Animal {public:    void speak() override {        std::cout << "Meow Meow!" << std::endl;    }};
int main() {    Animal* my_animal;
    my_animal = new Dog();    my_animal->speak();   // Calls Dog::speak() at runtime
    my_animal = new Cat();    my_animal->speak();   // Calls Cat::speak() at runtime
    delete my_animal;    return 0;}

In this example, the declared type of my_animal is always Animal*. However, at runtime, when it points to a Dog object, calling speak() will execute the Dog's version; when it points to a <code>Cat object, it will execute the <code>Cat's version. The compiler cannot determine at compile time what <code>my_animal will ultimately point to, so this decision is left to runtime.What are the underlying principles of polymorphism?The underlying principles of polymorphism mainly rely on two key mechanisms: virtual function table (vtable) and virtual pointer (vptr).<h3>1. Virtual Function Table (vtable)</h3>What is it: <code>vtable is a static, read-only array generated by the compiler for each class containing virtual functions at compile time. It is a table where each entry stores a function pointer.

Function: It stores the actual addresses of all virtual functions in the class. If a derived class overrides a virtual function, the corresponding entry in the vtable will be replaced with the address of the overridden function in the derived class.

How is it generated:

Base class Animal's vtable: It contains the address of the Animal::speak() function.

Derived class Dog's vtable: The compiler first copies the Animal‘s vtable, then replaces the address of the corresponding speak() function in the vtable with the address of Dog::speak().

2. Virtual Pointer (vptr)

What is it: vptr is a hidden, automatically added member variable that is added to the memory of any object that contains or inherits virtual functions.

Function: vptr stores the address of the vtable of the class to which the object belongs. It is usually located at the front of the object’s memory layout.

3. Addressing Process: How Polymorphism is Achieved

When calling a virtual function through a base class pointer or reference, the underlying execution process is as follows:

For example, with Animal* p = new Dog(); p->speak();:

Static Type vs Dynamic Type:

p‘s static type (declared type) is Animal*.

p‘s dynamic type (actual pointed type) is Dog.
Accessing vptr through Pointer: The compiler sees p->speak() and knows that speak() is a virtual function. It will not bind the call at compile time but will generate code that executes the following at runtime:
From the starting memory location of the object pointed to by p, find the hidden vptr.

Since p actually points to a Dog object, this <code>vptr stores the address of the <code>Dog class's <code>vtable.
Finding vtable through vptr: The program uses the address of vptr to find the Dog class's <code>vtable.
Looking up Function Address in vtable: The compiler determines at compile time the index position of the speak() function in the <code>vtable (for example, it is the first virtual function, index 0). The program will retrieve the corresponding function pointer from the <code>Dog's <code>vtable based on this index, which points to <code>Dog::speak().
Calling the Correct Function: Finally, the program calls the Dog::speak() function found in the <code>vtable.

Due to the presence of the virtual function pointer, virtual function class objects will have an additional pointer size compared to normal class objects. If a class has multiple virtual functions, it still only increases by the size of one pointer, as the virtual function pointer points to the entire virtual function table, not each virtual function corresponding to a pointer.

For example, assuming a 64-bit machine where the pointer size is 8 bytes.

Normal Class Object (No Virtual Functions)

#include <iostream>
class NormalClass {public:    int a; // 4 bytes    int b; // 4 bytes
    // No virtual functions};
int main() {    // Theoretical size of the object: 4 + 4 = 8 bytes    // Actual size may increase due to alignment, but we focus on the increment of vptr    std::cout << "NormalClass size: " << sizeof(NormalClass) << " bytes" << std::endl;    return 0;}

Virtual Class Object (With Virtual Functions)

#include <iostream>
class VirtualClass {public:    int a; // 4 bytes    int b; // 4 bytes
    virtual void func() {} // Introduces a virtual function};
int main() {    // Theoretical size: 4 (a) + 4 (b) + 8 (vptr) = 16 bytes    std::cout << "VirtualClass size: " << sizeof(VirtualClass) << " bytes" << std::endl;    return 0;}

Why can only base class pointers or references call dynamic polymorphism (i.e., runtime polymorphism)?

The core reason lies in the memory structure of the object and preventing object slicing

1. Ensuring the Existence and Correctness of vptr

Polymorphism depends on vptr: As mentioned earlier, the underlying principle of dynamic polymorphism is that the internal virtual function pointer (vptr) points to the correct virtual function table (vtable).

Accessing through Pointer/Reference: When you use Base* p or Base& r, you are operating on the address of the object itself. The compiler knows to look for the vptr at this address, and then follow the vptr to find the correct vtable.

Directly Calling through Object (Not Pointer/Reference): If you directly call a virtual function through an object, such as Dog myDog; myDog.speak();, the compiler will directly determine at compile time to call Dog::speak() (because it knows the exact type of <code>myDog, which is static binding), and will not use the dynamic lookup mechanism of <code>vptr and <code>vtable.

2. Preventing Object Slicing

This is the most critical reason. If you try to implement polymorphism through value passing, object slicing will occur, causing the polymorphic mechanism to fail.

Why are pointers/references dynamically bound while objects are statically bound?

1. Local Objects (Static Binding)

When you directly create an object, such as Dog myDog;, the compiler knows all the information about this object at compile time:

Static Type:Dog

Dynamic Type:Dog

Memory Size:Dog‘s size

Function Address:myDog.speak() corresponds to the function address (in the Dog's vtable at index N).

Since the type is determined and unchanging, the compiler will directly bind myDog.speak() to the actual address of <code>Dog::speak() at compile time for efficiency. It will skip the runtime query of vptr/vtable.

2. Pointers/References (Dynamic Binding)

When you use a base class pointer or reference, such as Animal* p_animal = &myDog;, the compiler only knows partial information at compile time:

Static Type:Animal* (the compiler only knows this is a pointer to Animal).

Dynamic Type:Unknown (only known at runtime whether it is Dog or <code>Cat).

Function Address:p_animal->speak() corresponds to a function address that is uncertain.

Since the compiler does not know at compile time what type of object p_animal will ultimately point to, it cannot determine in advance whether to call Animal::speak() or <code>Dog::speak(). Therefore, the compiler must generate a set of code to query vptr and <code>vtable at runtime to achieve dynamic binding.

Summary:

Local Objects: The type is determined at compile time, so static binding is used (highest efficiency).

Pointers/References: The type is uncertain at compile time (only the base class can be determined), so dynamic binding must be used (more flexible).

What is slicing in polymorphism?

Object slicing occurs when a derived class object is assigned to a base class object or when a derived class object is passed by value to a function that accepts a base class object.

In such operations, the part of the data unique to the derived class and the vptr will be “sliced off” or lost, leaving only the base class part copied.

See the following example:

#include <iostream>
#include <string>// Base class
class Person {protected:    std::string name;public:    Person(std::string n) : name(n) {}    virtual void introduce() const {        std::cout << "I am " << name << std::endl;    }};// Derived class
class Student : public Person {private:    std::string studentID;public:    Student(std::string n, std::string id)         : Person(n), studentID(id) {}
    void introduce() const override {        std::cout << "I am a student " << name << ", student ID is " << studentID << std::endl;    }
    void study() const {        std::cout << name << " is studying" << std::endl;    }};
int main() {    Student student("Zhang San", "2023001");
    // Case 1: Value assignment (slicing occurs)
    Person person = student;      person.introduce();  // Outputs "I am Zhang San" (the derived class's studentID is truncated, calling the base class version)
    // person.study();   // Compilation error: Person has no study() method
    // Case 2: Pointer/Reference (no slicing)
    Person* p = &student;      p->introduce();  // Outputs "I am a student Zhang San, student ID is 2023001" (polymorphism works, the object is still Student)

In this example, there are two classes: Person (base class) and Student (derived class).

Class	Unique/Inheriting Content	Additional Content in Derived Class (student specific)
Person (Base Class)	name (string)introduction() (virtual function)	None
Student (Derived Class)	Inherits all content from Person	studentID (string)study() (regular function)

Student class has an additional member variable studentID and a member function study()<code>.

When a Student object is created, its memory structure contains a complete Person sub-object (including <code>name and <code>vptr), plus its own unique <code>studentID member.

Why is this the output?

Case A: Object Slicing (Passing by Value)

Person person = student; // Slicing occurs
person.introduce();      // Calls introduce()// Output: I am Zhang San

Underlying Principle and Output Explanation:

Slicing Occurs: Person person = student; statement uses student object to initialize a new <code>Person object <code>person.

The compiler will copy the part of student that belongs to <code>Person.

student unique part (studentID: 2023001 and <code>vptr pointing to <code>Student's <code>vtable) is sliced off, not copied to <code>person.
Polymorphism Fails: The newly created person is a separate, complete <code>Person object. Its <code>vptr points to the <code>Person‘s vtable.
Result: When calling person.introduce()<code>, because <code>person is a <code>Person object, it calls <code>Person::introduce(), so the output is "I am Zhang San", without showing the student ID.

Case B: Correct Polymorphism (Pointer/Reference)

Person* p = &student; // Using pointer to point to student
p->introduce();       // Calls introduce()// Output: I am a student Zhang San, student ID is 2023001

Underlying Principle and Output Explanation:

No Slicing: Person* p = &student; statement simply lets the pointer p store the <code>student object's memory address.No copying or slicing occurs.<code>student object remains intact.
Dynamic Binding:

p‘s static type is Person*.

p‘s dynamic type is Student.

The compiler sees p->introduce() as a virtual function call, and it will check the vptr in the <code>student object.

vptr points to the Student‘s vtable, which records the address of Student::introduce().
Result: The program calls the overridden introduce() function in the derived class at runtime, which outputs the complete student information and student ID.

Summary:

Polymorphism is divided into static and dynamic binding:

Compile-time Polymorphism (Static Binding): Determined at compile time through function overloading or templates, with the highest efficiency.
Runtime Polymorphism (Dynamic Binding): Determined at runtime through the virtual function (virtual) mechanism, providing flexibility and extensibility in code.

The underlying principle of dynamic polymorphism is vptr and vtable::

Each object containing virtual functions has a hidden virtual function pointer (vptr) that points to the virtual function table (vtable).
vtable is a static array that stores the actual addresses of all virtual functions. At runtime, the program looks up the function address through vptr in the vtable.

To implement dynamic polymorphism, base class pointers or references must be used::

Reason: Pointers or references allow for indirect access, preserving the complete dynamic type (i.e., the correct vptr).
Direct Object Calls: Will result in static binding, as the compiler will determine the function address at compile time for efficiency, skipping the dynamic lookup mechanism.

Object Slicing is the main cause of polymorphism failure::

Slicing occurs when a derived class object is assigned by value or passed by value to a base class object.
The unique data and dynamic type information (correct vptr) of the derived class will be "sliced off", leaving only the base class part copied. The new object (base class copy) thus cannot call derived class methods, leading to runtime polymorphism failure.