虚默认析构函数与显式空析构函数的差异及相关技术疑问

Great question—let's dig into the details here, because the gap between = default destructors and empty ones is subtle but can have real implications for your code.

The core distinction boils down to how the compiler categorizes the destructor and the class:

• Triviality: A = default destructor preserves the class's triviality (if the implicit destructor would have been trivial). An empty user-provided destructor (~MyClass() {}) makes the class non-trivial. Trivial types qualify for raw memory operations like memcpy and enable faster optimizations, which non-trivial types don't.
• "Native" vs. User-Provided Logic: The defaulted destructor is exactly what the compiler would generate if you never declared a destructor at all. The empty destructor is a custom function (even though it does nothing), so the compiler treats it as a user-implemented piece of code—this can lead to minor differences in code generation, even if the end behavior looks the same.
• Base Class Handling: For classes inheriting from a virtual base destructor, both will properly override the virtual behavior, but the defaulted version aligns more closely with the compiler's implicit override logic, which can lead to cleaner, more consistent code generation.

This is a critical area where the two differ:

• ABI Consistency: Non-trivial classes (from empty destructors) have a different Application Binary Interface (ABI) than trivial ones. Different compilers (or even different versions of the same compiler) may interpret non-trivial destructor ABI details differently, leading to linker errors or undefined behavior when mixing shared libraries built with different tools.
• Best Practice for Shared Libs: Stick with = default when you want the compiler's implicit destructor behavior. This ensures your class's ABI matches what compilers expect for a "natural" type, minimizing portability risks. If you later need custom cleanup logic, switching to a user-provided destructor is fine—but be aware this will change the class's triviality and ABI, so you'll need to recompile dependent code.

You're spot-on that both are usually inlined, but there's a nuance:

• A = default destructor declared in a header is inherently inline—the compiler needs to generate its code wherever the class is used, so it can inline it aggressively, even across translation units with link-time optimization (LTO).
• An empty destructor is also almost always inlined by modern compilers, but since it's a user-provided function, the compiler might treat it as a "black box" in rare edge cases (though this is increasingly unlikely with modern optimizers). If you define the empty destructor in a .cpp file instead of the header, it won't be inlined across translation units at all.

• Debugging & Diagnostics: Some compilers emit different warnings or diagnostics for defaulted vs. empty destructors. For example, if your class has members with non-trivial destructors, both will call those member destructors (a common misconception is that empty destructors skip this—they don't!); but defaulted destructors might trigger clearer messages if something goes wrong with member cleanup.
• Future-Proofing: Using = default makes your intent explicit: you want the compiler's default behavior. If the C++ standard ever adjusts how implicit destructors work (unlikely for destructors, but possible for other special members), your code will automatically adopt the updated behavior. An empty destructor locks in the current behavior.
• Special Member Function Generation: Declaring any destructor (defaulted or empty) suppresses the compiler's automatic generation of move constructors/assignment operators (pre-C20; post-C20 rules are more nuanced). But = default doesn't add any extra changes beyond what declaring the destructor already does—whereas an empty destructor is just a user-provided implementation of that declared destructor.

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