《你真的了解C++吗》No.012：虚函数的底层代价——深入 vptr 与 vtable (终极进阶版)
导言：多态背后的物理真相
在 C++ 面向对象的设计中，“动态绑定”让我们能够通过基类接口操作异质的对象集合。但这种逻辑上的优雅，在底层是以牺牲内存确定性和指令执行效率为代价的。
一个关键的直觉：多态不是指针变聪明了，而是它指向的对象头部带了一张“地图”。本章将揭示这张地图（vtable）如何被读取，以及对象头部的指针（vptr）在整个生命周期中是如何保持其“本质”的。
一、 虚函数表 (vtable)：类级别的“静态手册”
每一个拥有虚函数的类，编译器都会在编译期为其在只读数据段（.rodata）构建一张虚函数表。
- 静态性：vtable 是一张静态的单例表。一旦程序编译完成，表中每个槽位存放哪个函数的地址就已经固定了。
- 重写的本质：派生类的 vtable 并不是重新发明轮子，而是对基类 vtable 的“拷贝与覆盖”。如果派生类没有重写某个虚函数，它的 vtable 槽位将直接存放基类函数的地址；一旦重写，该槽位的值就会被替换为派生类函数的地址。
二、 虚函数指针 (vptr)：对象的“身份烙印”
vptr是编译器偷偷塞进对象内存里的一个隐藏成员。它的存在，让原本“死”的数据块拥有了动态识别行为的能力。
1. vptr 的内容是不变的吗？
这是一个极具深度的观察。在对象的整个“成年期”（构造完成之后，析构开始之前），vptr的内容确实是绝对不变的。
- 谁变了？当你用一个
Base* p先指向DerivedA对象，再指向DerivedB对象时，改变的是指针变量p自身存储的地址值。 - 谁没变？
DerivedA对象头部的那个vptr始终指向DerivedA的 vtable。无论你用Base*还是DerivedA*去指它，它头部的那个“导航地址”都不会变。
2. “进化”与“退化”：唯一的变化窗口
vptr唯一发生变化的时候是在构造函数和析构函数执行期间：
- 构造时：随着构造函数由基类向派生类逐层执行，
vptr会像进度条一样，从指向基类 vtable 逐步更新为指向派生类 vtable。 - 析构时：顺序相反，
vptr会随着派生类部分的销毁，回退（退化）到指向基类的 vtable。
三、 性能损耗：三步跳转与内联之死
通过指针调用虚函数p->func()，在汇编层面会转化为一系列间接操作：
- 取地址：将
p指向的对象首地址（即vptr的位置）加载到寄存器。 - 取表：解引用该地址，获取
vtable的起始地址。 - 取函数并跳转：根据预先确定的偏移量（Offset），从
vtable中取出函数指针并执行call指令。
为什么它慢？
- Cache Miss：对象数据在堆上，vtable 在只读数据段，两者在物理内存中可能离得很远，极易导致 CPU 缓存失效。
- 分支预测失效：现代 CPU 会猜测下一条指令的位置。虚函数的跳转地址是运行期动态读取的，这会让 CPU 的预测器（Branch Predictor）面临巨大的压力。
- 内联屏蔽：编译器无法内联虚函数，因为内联需要“死代码”替换，而虚函数是“活”的。
四、 内存布局：不可忽视的“隐形成本”
vptr的引入不仅仅是多了一个指针的大小，它还扰乱了内存对齐。
- 空间膨胀：在 64 位系统下，
vptr占用 8 字节。 - 对齐陷阱：即使一个类只有一个
char（1字节），由于vptr位于开头且需要 8 字节对齐，编译器会强制将对象大小对齐到 16 字节。这在处理数百万个小对象时，会导致巨大的内存浪费。
五、 构造与析构的“多态禁忌”
问：为什么基类构造函数里调虚函数不能表现出多态？
答：因为此时vptr还是“雏形”。在基类构造函数执行时，派生类还未诞生，编译器为了防止你访问未初始化的派生类成员，故意让vptr指向基类的 vtable。此时，多态是“失效”的，这种行为由语言规范强制保证，以确保系统的稳定性。
总结：你是如何被“定位”的？
- 指针变了：意味着你换了一本书看。
- vtable 不变：意味着图书馆的索引表是固定的。
- vptr 不变：意味着这本书的封面（类型身份）在印好后就不会再改。
理解了这一点，你也就理解了 C++ 如何在“静态的语言”中通过“动态的指针”实现灵活的多态。
下一篇预告：在单继承中，对象只有一个vptr。但如果是多重继承呢？一个对象会有多张面孔吗？当我们将派生类指针强转为第二个基类指针时，指针的地址值竟然会发生“位移”？
➡️《你真的了解C++吗》No.013：多重继承的噩梦 (The Nightmare of Multiple Inheritance): 指针偏移与虚继承的秘密。
 前向填充)
