虚表指针（vptr）总是位于对象内存布局起始处；虚函数在虚表中索引由编译器静态分配但不可预测；调用需正确处理this和调用约定；虚表地址不可跨模块比较或用于constexpr。
虚表指针（vptr）在对象内存布局中的位置是固定的
在主流 ABI（如 Itanium C++ ABI、MSVC）中，vptr 作为虚函数表的入口指针，**总是位于对象内存布局的起始处**（即 reinterpret_cast 所指地址）。这是编译器生成代码时硬编码的约定，不是运行时可变的。因此获取虚表地址只需解引用对象首字节指针：
void** vtable = *reinterpret_cast<void>(&obj);</void>
注意：该操作依赖于对象有虚函数（即存在虚表），且 obj 必须是非空、已构造完成的对象实例。
虚函数在虚表中的偏移由编译器静态确定，不可跨平台直接计算
虚函数在虚表中的索引（即偏移量）由编译器在编译期按声明顺序分配，但具体顺序受多重继承、虚继承、访问控制等影响，**无法通过源码直观推导，也不能靠 sizeof 或 offsetof 计算**。例如：Base::foo() 在单继承下常为索引 0，但在带虚继承的菱形结构中可能被移到后续位置。实际验证方式只有两种：
- 用调试器（如 GDB）查看
vtable内容：p/x *(void**)(&obj)，再逐项反汇编比对符号 - 借助编译器扩展（如 GCC 的
__builtin_dump_struct）或生成汇编（g++ -S）观察调用指令中的 offset
没有通用公式，每个类、每个编译器版本都可能不同。
通过虚表索引调用成员函数必须手动补全 this 指针和调用约定
虚表中存储的是“裸函数指针”，调用时需显式传入 this，且必须匹配目标平台的调用约定（如 thiscall 在 MSVC x86 下隐含 this 在 ecx，而 x64 下统一用寄存器传参）。安全做法是使用函数指针类型强制转换：
using FuncPtr = void (Base::*)();<br>FuncPtr f = reinterpret_cast<funcptr>(vtable[0]);<br>(obj.*f)(); // 编译器自动处理 this 和调用约定</funcptr>
若强行用 typedef void (*RawFunc)(void*) 并传 &obj，在 x64 Windows 下会因寄存器使用冲突导致崩溃；在 Linux x86_64 上虽可能“碰巧”成功，但属于未定义行为。
虚表地址本身不等于类的静态地址，且不能用于跨模块比较
同一个类在不同动态库（.so/.dll）中，其虚表地址通常不同——链接器为每个模块生成独立副本。因此不能用 vtable == other_vtable 判断类型相等；应使用 dynamic_cast 或 typeid。另外，虚表地址不是常量表达式，constexpr 无法捕获它；试图取 &Base::foo 得到的是“成员函数指针”，其二进制格式与虚表中存储的地址不兼容（前者含调整偏移，后者是纯跳转地址），二者不可互换。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
