History: In C++98, resource management followed the Rule of Three: if a class needed a custom destructor, copy constructor, or copy assignment operator, it likely needed all three. When C++11 introduced move semantics, this became the Rule of Five, adding move constructor and move assignment. The standard committee chose a conservative approach: declaring any destructor (even trivial ones) inhibits implicit generation of move operations to prevent accidental shallow moves of resources managed by destructors.
Problem: When you write ~MyClass() = default; inside the class definition, you create a "user-declared" destructor. Per the C++ standard ([class.copy.ctor]/3), this presence suppresses the implicit declaration of both the move constructor and move assignment operator. Consequently, the compiler treats the class as copy-only, silently falling back to expensive copy semantics during std::vector reallocations or return-by-value optimizations, even though the destructor performs no actual work.
Solution: To maintain implicit move generation, declare the destructor only inside the class and provide the defaulted definition outside:
class Optimized { public: ~Optimized(); // Only declared here std::array<char, 4096> buffer; }; Optimized::~Optimized() = default; // Defined outside
This makes the destructor "user-provided" but not "user-declared" at the point where the compiler decides to generate moves. Alternatively, explicitly default all five special members, or preferably follow the Rule of Zero by replacing raw resources with std::unique_ptr or containers.
We encountered this in a high-frequency trading engine processing MarketDataPacket objects. The class held a fixed 4KB buffer for network data:
class MarketDataPacket { public: ~MarketDataPacket() = default; // Written in header for "clarity" char buffer[4096]; };
After migrating to C++11, latency profiling revealed 40% of CPU cycles spent in memcpy despite returning packets by value. The culprit was the in-class defaulted destructor, which inadvertently deleted implicit moves and forced copies during std::vector growth and function returns.
Solution 1: Explicitly declare noexcept move constructor and assignment. This immediately fixes the performance issue by enabling moves. However, it requires manually maintaining these functions when adding members, risks exception specification mismatches if raw pointers are involved, and adds boilerplate that violates the Rule of Zero.
Solution 2: Move the destructor definition to the .cpp file with MarketDataPacket::~MarketDataPacket() = default;. This restores compiler-generated moves while keeping the destructor trivial. It maintains zero-overhead abstraction and allows compiler optimizations like eliding destructor calls for unused objects. The only drawback is requiring a separate compilation unit, which was acceptable.
Solution 3: Replace the raw buffer with std::vector<uint8_t> or std::unique_ptrstd::byte[]. This achieves perfect Rule of Zero compliance. However, this introduces indirection or heap allocation overhead unacceptable in microsecond-sensitive trading paths where cache locality is critical.
We selected Solution 2. By moving the defaulting outside the class, we restored implicit moves, reduced packet processing latency from 12μs to 3μs, and maintained trivial destructibility allowing aggressive compiler optimizations.
Why does the compiler distinguish between in-class and out-of-class defaulting when the semantics are identical?
The difference is syntactic, not semantic. C++ uses a single-pass parsing model for class definitions. When the compiler reaches the closing brace of the class, it must decide whether to generate implicit move operations. If it sees = default inside, the destructor is "user-declared" at that point, triggering the suppression rules per [class.copy]/7. The compiler cannot "look ahead" to the outside definition to change this decision. This is a fundamental constraint of C++'s compilation model.
Does marking the destructor noexcept restore the implicit moves?
No. The suppression of implicit move generation depends solely on whether the destructor is user-declared, not on its exception specification. While marking moves noexcept is crucial for them to be used in std::vector reallocations, merely adding noexcept to a defaulted destructor inside the class does not bring back the deleted move operations. You must either move the definition outside or explicitly default the moves.
How does a user-declared destructor affect aggregate initialization?
A class with any user-declared destructor ceases to be an aggregate. This is often more disruptive than losing moves. It means losing designated initializers (C++20) and the ability to use brace-enclosed initializer lists without explicit constructors. Many developers expect aggregate initialization to work and are surprised when it fails:
struct Config { ~Config() = default; // Breaks aggregation int value; }; // Config c{42}; // Error: no matching constructor
This happens because the presence of a user-declared destructor forces the class to have non-trivial destruction semantics in the type system, disqualifying it from aggregate status regardless of actual complexity.