为何为无虚函数类新增虚函数未破坏二进制兼容性？

这是个非常有意思的实验，你观察到的现象其实涉及到C++编译器对非多态类的处理逻辑，以及二进制兼容性破坏的前提条件，咱们一步步拆解：

1. 为什么你的实验没有触发兼容性问题？ #

你遇到的核心情况是：旧的test.exe是基于无虚函数的FastString头文件编译的，而更新后的DLL虽然给类加了虚函数，但test.exe的代码完全没有触及到新的虚函数和对应的vptr布局。具体来说：

• 当test.exe编译时，编译器看到的FastString是没有虚函数的普通类，因此会对length()做静态绑定——直接通过函数地址（或DLL导入表）调用，不会涉及任何对象内存布局的依赖。
• 如果你给FastString新增的isEmpty()只是在DLL里实现，但test.exe既没有调用它，也没有通过指针/引用进行多态操作，那么：
  • 要是你的FastString没有数据成员（从实验正常输出推测大概率是这样），哪怕DLL里的对象布局新增了vptr，length()方法因为不需要访问对象内存，this指针的偏移错误也不会引发实际问题。
  • 就算类有数据成员，只要test.exe没有直接访问对象内存（比如只是调用非虚成员函数），也可能暂时不暴露问题——但这属于“未定义行为”，换个编译器、加个数据成员就会立刻崩溃。

另外你调试时没看到_vptr，大概率是因为test.exe用的是旧的符号信息（.pdb/.sym文件），调试器不知道DLL里的类已经新增了虚函数，所以不会显示vptr字段。

2. 什么时候新增虚函数才会真正破坏二进制兼容性？ #

KDE Wiki里说的“破坏兼容性”是有前提的：当旧代码依赖类的内存布局时，新增虚函数才会出问题。比如以下场景：

• 旧代码通过指针/引用对FastString进行多态操作（哪怕是未来可能的操作）；
• 旧代码直接访问FastString的内存（比如用memcpy复制对象、强制类型转换、访问成员变量的偏移）；
• 旧代码创建了FastString的对象数组（新增vptr会改变对象大小，导致数组访问越界）。

3. vtable的生成时机 #

你猜的完全没错：vtable是在编译期生成的。每个包含类虚函数实现的编译单元（.cpp文件），编译器都会生成对应的vtable副本，然后在链接阶段（静态链接或动态链接的加载阶段）合并成唯一的vtable实例。

对于动态链接库来说，DLL的vtable是完全独立于exe的——exe里不会包含DLL类的vtable，所有虚函数的调用都会通过DLL导出的符号或vptr间接跳转。

内容的提问来源于stack exchange，提问作者Leo