基类析构函数中调用带实现的纯虚函数引发崩溃的原因及标准规定合理性问询

这是个戳中C++虚函数机制深层细节的好问题！咱们一步步拆解你遇到的现象，再聊聊标准为什么这么规定：

一、为什么3B会崩溃，而2B却能正常运行？ #

首先得把构造/析构阶段的虚函数调用规则掰明白：当你在基类的构造或析构函数里操作对象时，这个对象的动态类型就严格是当前正在执行构造/析构的基类类型——派生类的成员已经被销毁（析构时）或者还没初始化（构造时），所以C++会强制把对象的虚表切换成基类的虚表，杜绝调用派生类函数的可能。

那为什么同样是调用g()，直接写g();（2B）没问题，用p->g();（3B）就炸了？

• 对于直接调用g();：编译器在基类析构函数中看到这个调用时，能做静态绑定优化——它明确知道当前在基类的上下文里，直接调用基类已经提供的g()实现，完全不需要走虚表查找流程。这就是你2B能正常输出的原因，但要注意：这个优化是编译器的“善意之举”，标准并不保证所有编译器都这么做，本质上这属于未定义行为的“侥幸生效”情况。
• 对于p->g();：这里p是AbstractBase*类型，编译器会严格按照虚函数的常规调用逻辑走——去当前对象的虚表里找g()的入口。但基类的虚表中，纯虚函数g()的条目是一个指向“纯虚函数调用陷阱”的特殊指针（通常是直接触发std::terminate()的逻辑），哪怕你给基类的g()写了实现！

这里要纠正你之前的错误认知：纯虚函数的作用不只是编译时强制派生类实现它，它的核心语义是基类不为该函数提供有效的虚表入口。你给纯虚函数写的实现，只是供派生类显式调用的“工具函数”，不会被放到基类的虚表里。所以当你通过指针触发虚调用时，找到的是陷阱函数，直接导致程序崩溃。

而普通虚函数f()就不一样：基类的虚表里f()的条目就是基类自己的实现，所以p->f();（3A）能正常调用基类的f()，不会崩溃。

二、为什么标准不区别对待“带实现的纯虚函数”？ #

你疑惑的点非常到位：既然我给纯虚函数写了实现，为什么标准还要把这种情况定为未定义行为？其实这和C++的设计哲学、语义一致性有关：

1. 语义一致性优先：纯虚函数的核心定义就是“基类不提供该函数的虚实现”，写不写函数体不改变这个核心语义。函数体只是额外提供的、供派生类显式调用的逻辑，不是基类虚表的一部分。如果标准为了这个小众特性修改规则，会破坏纯虚函数的语义统一性，让开发者更难理解。
2. 避免规则复杂度爆炸：C++的规则已经够复杂了，如果要区别对待“有实现的纯虚函数”和“无实现的纯虚函数”，编译器需要额外处理大量特殊情况——比如在构造/析构阶段判断纯虚函数是否有实现，再调整虚表或调用逻辑。这会大幅增加编译器的实现成本，也会让语言规则更难掌握。
3. 安全性导向：构造/析构阶段调用虚函数本身就是高风险操作，很容易因为开发者对动态类型的误解出问题。标准干脆把所有“在基类构造/析构中通过虚调用触发纯虚函数”的情况都定为未定义行为，本质上是在提醒开发者：这种写法本身就很危险，不要依赖任何侥幸生效的情况。

最后再总结几个关键结论 #

• 在基类构造/析构中，直接调用纯虚函数能运行是编译器优化，不具备可移植性，属于未定义行为；
• 通过指针/引用触发纯虚函数的虚调用，在基类构造/析构中一定会触发陷阱（因为基类虚表中该位置是陷阱入口）；
• 纯虚函数的实现只是“额外福利”，不改变它在基类虚表中的特殊地位，标准不会为这个小众场景开特例。

内容来源于stack exchange