虚默认析构函数：头文件与源文件定义的差异及影响分析

没错，这两种写法确实会造成明显的行为差异，特别是在跨DLL边界调用、结合智能指针或者依赖前向声明的场景下。下面我分情况给你拆解清楚：

1. 头文件内联默认析构（情况1）的坑点 #

当你在头文件里写DLL_API virtual ~Derived() = default;时，这个析构函数会被标记为内联函数，随之而来几个关键问题：

• 多实例化风险：每一个包含Derived.hpp的编译单元（不管是DLL内部还是外部客户端代码）都会生成一份析构函数的副本。如果编译器选择内联它，DLL的导出符号表里可能压根不会出现这个析构函数的符号；要是没被内联，多个编译单元的副本可能引发符号冲突，或者跨DLL调用时执行错误的析构逻辑。
• 跨DLL的智能指针陷阱：假设Derived里有一些只有DLL内部才可见的私有成员（比如依赖DLL内部的类型或者资源），客户端编译单元生成的析构副本根本没法正确销毁这些成员，直接触发未定义行为——比如内存泄漏、资源释放出错之类的。
• 前向声明场景的编译/运行故障：如果客户端代码只做了Derived的前向声明，用std::unique_ptr<Derived>持有对象，编译器在实例化unique_ptr的析构逻辑时，需要Derived的完整定义（要确认析构函数的可访问性和具体行为），这时候直接就会报编译错误。哪怕用std::shared_ptr<Base>（Base有完整定义），要是客户端编译单元生成的vtable条目指向自己的析构副本，也可能导致析构逻辑不一致。

2. 源文件中默认定义析构（情况2）的优势 #

把析构函数的声明留在头文件，定义放到Derived.cpp里写成Derived::~Derived() = default;，就能彻底规避这些问题：

• 唯一符号实例：析构函数只会在Derived.cpp里被定义一次，DLL会导出这个唯一的符号。所有调用Derived析构的地方（不管是DLL内部还是外部）都会链接到这个统一的实例，保证行为完全一致。
• 跨DLL边界的安全性：不管客户端知不知道Derived的内部细节，调用析构时都会执行DLL内部的逻辑，能正确销毁所有成员（包括DLL的私有资源）。
• 前向声明场景更友好：如果客户端只做了Derived的前向声明，用std::shared_ptr<Base>（Base带虚析构）销毁对象时，会通过vtable正确跳转到DLL里的Derived析构函数，完全没问题。对于std::unique_ptr<Derived>，只要客户端包含了Derived.hpp（里面有析构的声明），链接时会自动找到DLL里的析构符号，编译和运行都正常。

总结：哪些场景必须用源文件定义？ #

你一定要选第二种写法（源文件默认定义）的场景包括：

• 你的类需要跨DLL边界被使用，而且包含非平凡成员（或者依赖DLL内部资源）；
• 存在客户端仅通过前向声明使用你的类，还结合了智能指针（尤其是std::unique_ptr）的情况；
• 你需要确保类的析构逻辑在所有调用处都保持一致，避免出现未定义行为。

要是你的类只在单个编译单元（或者同一个DLL内部）使用，两种写法的差异可以忽略，但第二种写法依然是更健壮的实践。

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