vptr位于对象内存布局最开头，即对象地址处；它是一个隐式插入的指针，指向编译器生成的只读虚函数表（vtable），其大小已计入sizeof结果。
虚函数表指针（vptr）在对象内存布局中的位置
在绝大多数主流编译器（如 GCC、Clang、MSVC）中，vptr 位于对象内存布局的最开头——也就是对象地址处。这意味着对一个含虚函数的类实例取地址，得到的指针值，就是 vptr 的地址；解引用一次，得到的就是 vtable 的首地址。
但注意：这不是 C++ 标准保证的行为，而是 ABI 约定（如 Itanium C++ ABI 或 MSVC ABI）。所以不能在可移植代码中依赖它，仅限调试、逆向或底层分析场景。
- 若类无虚函数，对象没有
vptr，访问会出错或读到垃圾值 - 多重继承时，
vptr可能不止一个（例如派生类从多个带虚函数的基类继承），但“主基类”的vptr仍在对象起始处 - 空基类优化（EBO）一般不影响
vptr位置，但可能让对象大小为 1（即使有虚函数）
用 GDB 快速查看 vptr 和 vtable 内容
在调试时，最直接的方式是用 GDB 打印对象起始地址处的指针，再逐级解引用查看虚函数地址：
gdb$ p/x *(void**)(&obj) gdb$ p/x *(void**)*(void**)(&obj) gdb$ x/5a *(void**)(&obj)
其中：&obj 是对象地址；(void**)&obj 把它转成指向指针的指针；第一次解引用拿到 vtable 地址；第二次解引用或 x/5a 可看到前几个虚函数入口。
立即学习“C++免费学习笔记（深入）”；
- 确保编译时未开启
-fno-rtti（否则 vtable 仍存在，但调试信息可能缺失） - Release 模式下符号可能被优化掉，建议用
-O0 -g编译测试代码 - MSVC 下可用
dt /v命令配合 WinDbg，但需 PDB 符号且格式不同
用 reinterpret_cast 在代码中安全读取 vptr（仅限调试）
虽然不推荐，但在可控的调试辅助工具里，可以这样提取 vptr：
struct Base { virtual ~Base() = default; };
Base obj;
void* vptr = *reinterpret_cast<void**>(&obj);这里 *reinterpret_cast<void>(&obj)</void> 就是读取对象头的指针值。注意：
- 必须确保
Base有虚函数（否则vptr不存在，行为未定义） - 不能用于多态对象的子类指针（如
Derived*转Base*后取地址），因偏移可能变化 -
vptr值本身不可调用，需再解引用才能得到函数指针，且类型需强转（如typedef void (*func_t)(); func_t f = (func_t)vtable[0];）
为什么 sizeof 不体现 vptr 占用？
sizeof 返回的是对象的“可见大小”，而 vptr 是编译器隐式插入的成员，它确实占空间——你看到的 sizeof 结果已经包含了 vptr 的字节数（通常是 8 字节，在 64 位系统上）。
常见误解是以为 “没写成员变量，sizeof 应该是 0”，但标准规定空对象至少为 1 字节；而一旦加虚函数，大小立刻跳到指针宽度（如 8），这增加的部分基本就是 vptr。
- 验证方式：对比
struct A {};和struct B { virtual ~B(){}; };的sizeof - 成员函数指针、lambda 捕获等不会影响
vptr位置，但可能改变对象整体对齐 - 静态断言
static_assert(sizeof(B) == sizeof(void*));在单继承无数据成员时通常成立，但别当成通用规则
真正容易被忽略的是：vtable 本身不在对象内，而是在只读数据段（.rodata），每个类一份；vptr 只是指向它的指针。查 vptr 容易，但想遍历整个 vtable 并识别函数名，就得结合调试符号或 DWARF 信息——那已经是调试器的工作了。
