22、函数与虚函数表：C++虚函数的实现机制，vptr与vtable，动态绑定的开销

说到C++的虚函数，很多人第一反应就是「多态」。但虚函数到底是怎么工作的？vptr和vtable又是什么？动态绑定真的那么慢吗？今天我就把这些底层机制掰开揉碎了讲清楚。

先抛个问题：为什么C语言里没有虚函数，而C++有？说白了，C语言的结构体里只能放数据，不能放函数指针表。C++为了支持运行时多态，在对象的内存布局里偷偷塞了一个指针——这就是vptr。

虚函数表（vtable）是什么？

每个包含虚函数的类，编译器都会为它生成一张虚函数表。这张表本质上是一个函数指针数组，里面按声明顺序存放着所有虚函数的地址。

我当年第一次看vtable时，觉得它就是个跳转表。你想想看，如果类里有三个虚函数，vtable里就有三个槽位。子类如果重写了某个虚函数，就把对应槽位的指针换成自己的函数地址。

class Base {
public:
    virtual void func1() { printf("Base::func1\n"); }
    virtual void func2() { printf("Base::func2\n"); }
    void func3() { printf("Base::func3\n"); }  // 非虚函数
};

class Derived : public Base {
public:
    virtual void func1() override { printf("Derived::func1\n"); }
    virtual void func2() override { printf("Derived::func2\n"); }
};

// 内存布局示意
// Base对象: [vptr] [其他成员]
// Derived对象: [vptr] [Base成员] [Derived成员]
// 
// Base的vtable: [&Base::func1] [&Base::func2]
// Derived的vtable: [&Derived::func1] [&Derived::func2]

vptr：藏在对象里的指针

每个含有虚函数的对象，在内存开头都有一个隐藏的vptr指针。这个指针指向所属类的vtable。对象构造时，vptr会被设置为正确的值。

我记得有一次调试一个诡异的崩溃，发现是对象在构造期间调用了虚函数。为什么？因为构造时vptr还没指向子类的vtable，调用的其实是基类的版本。这就是为什么C++不建议在构造函数里调用虚函数。

动态绑定的完整流程

当通过基类指针或引用调用虚函数时，编译器不会直接生成call指令，而是生成一段间接调用的代码：

1. 从对象中取出vptr
2. 通过vptr找到vtable
3. 在vtable中根据偏移找到对应的函数指针
4. 通过函数指针调用函数

Base* p = new Derived();
p->func1();  // 动态绑定

// 编译器生成的伪代码：
// 1. 取出vptr: vptr = p->__vptr
// 2. 找到vtable: vtable = vptr
// 3. 取函数指针: func = vtable[0]  // func1在槽位0
// 4. 调用: func(p)

动态绑定的开销分析

很多人觉得虚函数慢，其实要看场景。我做过一些性能测试，发现动态绑定的开销主要来自三个方面：

开销来源	说明	典型耗时
间接寻址	多了一次指针解引用	1-2个CPU周期
无法内联	编译器不知道最终调用哪个函数	取决于函数大小
分支预测	间接跳转可能影响分支预测	10-20个周期（预测失败时）

说实话，对于大多数应用场景，这点开销可以忽略不计。只有在热循环里频繁调用虚函数时，才需要考虑优化。

vptr的初始化时机

vptr的初始化发生在构造函数中。具体来说：

• 进入基类构造函数体之前，vptr指向基类的vtable
• 基类构造函数执行完毕后，vptr被更新为派生类的vtable
• 如果有多层继承，每层构造时都会更新vptr

嗯，这里要注意：析构函数中vptr的变化是反过来的。先指向派生类的vtable，然后随着析构的进行，逐步回退到基类的vtable。这就是为什么不要在析构函数中调用虚函数——你永远不知道当前调用的是哪个版本。

多重继承下的vtable

多重继承时，事情就变得复杂了。每个基类子对象都有自己的vptr，派生类需要维护多个vtable指针。

class A {
public:
    virtual void fa() {}
};

class B {
public:
    virtual void fb() {}
};

class C : public A, public B {
public:
    virtual void fc() {}
};

// C对象的内存布局：
// [A部分: vptr_A] [A成员] [B部分: vptr_B] [B成员] [C成员]
// 
// vptr_A指向的vtable: [&A::fa] [&C::fc]  // 注意fc被追加到A的vtable
// vptr_B指向的vtable: [&B::fb] [thunk]    // thunk用于调整this指针

你可能会问：为什么C的虚函数fc要放在A的vtable里？因为C++规定，派生类的虚函数地址要放在第一个基类的vtable中。这样通过第一个基类指针调用时，偏移量是连续的。

虚函数与性能的权衡

我见过不少团队因为担心虚函数性能，强行用switch-case替代多态。结果代码变得又臭又长，维护成本飙升。其实虚函数的开销真的没那么大。

做个简单计算：假设每秒调用1000万次虚函数，每次多花5个CPU周期（3GHz的CPU），总耗时也就16毫秒。这点时间在大多数应用里根本感觉不到。

如何查看vtable？

如果你用的是GCC，可以用-fdump-class-hierarchy选项来查看类的vtable布局：

// 编译命令：g++ -fdump-class-hierarchy test.cpp
// 输出文件：test.cpp.002t.class

// 输出示例：
// Vtable for Base
// Base::_ZTV4Base: 4 entries
// 0     (int (*)(...))0
// 8     (int (*)(...))(& _ZTI4Base)
// 16    (int (*)(...))Base::func1
// 24    (int (*)(...))Base::func2
//
// Vtable for Derived
// Derived::_ZTV7Derived: 4 entries
// 0     (int (*)(...))0
// 8     (int (*)(...))(& _ZTI7Derived)
// 16    (int (*)(...))Derived::func1
// 24    (int (*)(...))Derived::func2

看到没？vtable的前两个槽位不是函数指针，而是用于RTTI（运行时类型识别）的信息。第一个是偏移量，第二个是指向type_info对象的指针。真正的虚函数从第三个槽位开始。

总结一下

虚函数的实现机制，说白了就是通过vptr和vtable做了一层间接跳转。这层间接带来了灵活性，也付出了一点性能代价。但在我看来，这点代价换来的代码可维护性，绝对值。

最后说一句：理解vptr和vtable，不仅是为了面试。当你遇到诡异的崩溃、内存泄漏、或者性能问题时，这些底层知识能帮你快速定位问题。我就在一个线上问题中，通过分析vtable的布局，发现了一个因为对象切片导致的虚函数调用错误。