调用C++虚函数时为何需要虚表？为何无法编译时确定函数地址？

Great question—this cuts straight to the core of how dynamic polymorphism works in C++. Let’s break down why compilers can’t just hardcode function addresses at compile time, and why vtables are essential.

The Problem: Compile-Time vs. Run-Time Type Information #

Your intuition is correct if you’re calling a function directly on a concrete object (like d1.function1()). In that case, the compiler knows exactly what type d1 is, so it can resolve the function address immediately and generate direct calls.

But C++’s polymorphism relies on a key scenario where the compiler can’t know the actual object type at compile time: when using base class pointers or references to point to derived class objects.

Take this example:

#include <iostream>

class Base {
public:
    virtual void function1() { std::cout << "Base::function1\n"; }
};

class D1 : public Base {
public:
    void function1() override { std::cout << "D1::function1\n"; }
};

class D2 : public Base {
public:
    void function1() override { std::cout << "D2::function1\n"; }
};

// This function takes a Base*—but what's the actual type of the object?
void executeFunction(Base* obj_ptr) {
    obj_ptr->function1(); // Compiler can't know which function to call here at compile time!
}

int main() {
    Base base_obj;
    D1 d1_obj;
    D2 d2_obj;

    executeFunction(&base_obj);
    executeFunction(&d1_obj);
    executeFunction(&d2_obj);

    // Even trickier: what if the object type depends on user input?
    int user_choice;
    std::cin >> user_choice;
    Base* dynamic_obj = nullptr;
    if (user_choice == 1) dynamic_obj = new D1();
    else if (user_choice == 2) dynamic_obj = new D2();
    else dynamic_obj = new Base();
    executeFunction(dynamic_obj);

    delete dynamic_obj;
    return 0;
}

In the executeFunction function, the compiler only sees a Base*—it has no way of knowing whether this pointer points to a Base, D1, or D2 object. That decision is made at runtime (maybe based on user input, file data, or some other dynamic condition).

How Vtables Solve This #

Vtables (virtual function tables) are the compiler’s way of handling this uncertainty:

• Every class with at least one virtual function gets its own vtable—a static array that stores the addresses of all its virtual functions (including overrides from base classes).
• Each object of such a class has a hidden vptr (virtual pointer) that points to its class’s vtable.

When you call a virtual function via a base pointer:

1. The program uses the object’s vptr to locate its class’s vtable at runtime.
2. It looks up the address of the correct function in the vtable.
3. It calls that function.

This is called dynamic dispatch—the function call is resolved at runtime, not compile time, based on the actual type of the object.

What If We Didn’t Have Vtables? #

Without vtables, the compiler would have to resolve the function call based on the static type of the pointer (in our example, Base*), meaning it would always call Base::function1(), even if the pointer points to a D1 or D2 object. That would break polymorphism entirely—one of C++’s most powerful features.

Edge Cases Where Vtables Still Matter #

Even beyond basic polymorphism, vtables enable other important features:

• Abstract base classes: Classes with pure virtual functions rely on vtables to enforce that derived classes provide implementations.
• Runtime type information (RTTI): Features like dynamic_cast use vtables to determine the actual type of an object at runtime.

内容的提问来源于stack exchange，提问作者markzzz