虚函数表（vtable）是编译期生成的类级只读函数指针数组，存于.rodata段；对象内仅含指向它的vptr（通常位于起始处），sizeof增加即因vptr而非整表。
虚函数表（vtable）本身不存于对象内部，而是一个全局只读的函数指针数组，位于程序的 .rodata 或代码段；每个含虚函数的对象只存一个指向它的指针（vptr），通常在对象内存起始处。
虚函数表存储位置：不是堆也不是栈，是只读数据段
虚函数表在编译期就生成完毕，内容固定（函数地址不会运行时改），所以编译器把它放进 .rodata 段（只读数据段）或紧邻代码段。它和普通函数一样，生命周期贯穿整个程序运行期，且所有同类对象共享同一份 vtable。
常见误判是以为 vtable 随对象分配在堆/栈上——实际你用 sizeof 查对象大小，只会多出一个指针宽度（8 字节 on x64），那只是 vptr，不是整张表。
- 验证方式：调试时对对象取地址，再解引用其首字节得到
vptr值，然后用该值去内存窗口查看——你会发现那是一串连续的函数指针，且地址落在低地址段（如0x00007ff...），与&A::func1地址同属一个内存区域 - 不能修改：尝试写入 vtable 内存会触发段错误（SIGSEGV），因为它被 mmap 为 PROT_READ
- 注意：RTTI 相关信息（如类型名字符串、type_info 结构）也常和 vtable 紧邻存放，但属于另一块独立只读内存
vptr 在对象中的位置：总是最前面，但受对齐影响可能有填充
只要类声明了任一虚函数（包括虚析构），编译器就会在对象内存布局最前端插入一个隐藏成员 vptr。它的类型是 void*（或等效指针），大小等于目标平台指针宽度。
但要注意：如果类里第一个显式成员是 double 或 long long 这类需要 8 字节对齐的类型，而 vptr 又恰好是 8 字节，那通常无需填充；可一旦类启用了 #pragma pack(n) 或成员类型对齐要求冲突，vptr 后面可能出现填充字节。
- 典型布局（x64，无特殊 pack）：
vptr（8B）→ 成员变量（按声明顺序、对齐规则排布） - 反例：若类定义为
class A { char c; virtual void f(); };，则vptr后大概率有 7 字节填充，才能保证后续成员对齐 - 别依赖偏移量硬编码：不同编译器（MSVC / GCC / Clang）、不同标准库实现，vptr 是否严格在 offset 0 可能略有差异（尤其多重继承时）
虚函数在 vtable 中的排列顺序：严格按声明顺序，不按定义顺序
vtable 是个简单数组，索引 0 存第一个声明的虚函数地址，索引 1 存第二个……跟函数体在哪定义、是否 inline 完全无关。派生类重写基类虚函数时，对应槽位会被替换；新增虚函数则追加到末尾（单继承下）。
这个顺序直接影响 reinterpret_cast 手动调用虚函数的可靠性——比如你知道 Base::foo 是第 2 个虚函数，就可以用 (*(*((void***)obj))[2])() 强行调用（不推荐，仅用于调试或 hook 场景）。
- 注意：析构函数也占一个槽位，即使没显式声明虚析构，编译器合成的也会进表
- 纯虚函数（
= 0）在 vtable 中填的是“纯虚函数调用”桩地址（如__cxa_pure_virtual），不是空指针 - 多重继承时，派生类会有多个
vptr，各自指向不同基类的 vtable，顺序取决于继承列表中基类出现的先后
为什么不能直接取 vtable 地址做跨类比较
看起来两个对象的 vptr 值相等就能判断类型相同？不行。因为：
- 空基类优化（EBO）可能导致不同类的 vtable 地址意外重合（极少见但合法）
- 模板实例化生成的类，即使逻辑相同，vtable 也是独立副本
- 最可靠的方式永远是
dynamic_cast或typeid，它们底层用的是 RTTI 而非裸指针比对 - 手动读 vtable 第一个元素（RTTI 指针）再解析 type_info，技术上可行但 ABI 不稳定，GCC 和 MSVC 的 layout 不兼容
真正需要 inspect vtable 的场景极少，基本只出现在调试器插件、二进制 patch 工具或极端性能敏感的 dispatch 优化中——日常开发里，把 vptr 当黑盒，专注接口契约即可。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
