Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt

Use this file to discover all available pages before exploring further.

A constexpr destructor is a destructor declared with the constexpr specifier, introduced in C++20, which permits an object to be destroyed during constant evaluation. It modifies the language rules for literal types by allowing objects with non-trivial destructors to be instantiated, manipulated, and safely destroyed entirely at compile-time.

Syntax

The constexpr keyword is applied directly to the destructor declaration. It can be used on user-defined destructors or explicitly defaulted ones:
class NonTrivialLiteral {
public:
    constexpr NonTrivialLiteral() {}
    
    // User-defined constexpr destructor
    constexpr ~NonTrivialLiteral() {
        // Cleanup logic valid in constant evaluation
    }
};

class TrivialLiteral {
public:
    constexpr TrivialLiteral() = default;
    
    // Defaulted constexpr destructor
    constexpr ~TrivialLiteral() = default;
};

Technical Mechanics and Constraints

To be valid and executable during constant evaluation, a constexpr destructor must adhere to strict language rules:
  1. Constant Expression Compliance: The body of the destructor cannot contain operations that are invalid in a constant expression context. It cannot call non-constexpr functions, execute inline assembly, or invoke undefined behavior.
  2. Transient Memory Deallocation: If the object allocated dynamic memory during constant evaluation (via a constexpr constructor or member function), that exact memory must be deallocated before the constant evaluation completes. The constexpr destructor is the mechanism that executes the delete expression at compile-time. Memory cannot “escape” compile-time to run-time.
  3. Virtual Destructors: As of C++20, virtual destructors can also be declared constexpr. This allows polymorphic destruction during constant evaluation, provided the dynamic type of the object is known at compile-time.
  4. Implicit constexpr: A defaulted destructor (= default) is implicitly constexpr if the destructors of all its base classes and non-static data members are also constexpr.

Execution Behavior

When an object with a constexpr destructor is created within a constexpr function or a consteval context, the compiler tracks its lifecycle. When the object goes out of scope, the compiler evaluates the destructor just as it would evaluate a standard constexpr function.
class CompileTimeBuffer {
    int* buffer;
public:
    constexpr CompileTimeBuffer(int size) : buffer(new int[size]) {}
    
    // Evaluated by the compiler to prevent compile-time memory leaks
    constexpr ~CompileTimeBuffer() {
        delete[] buffer;
    }
};

constexpr bool evaluate_destruction() {
    // Object created in constant evaluation context
    CompileTimeBuffer temp_buffer(10);
    
    // As temp_buffer goes out of scope, ~CompileTimeBuffer() is invoked.
    // If the destructor were not constexpr, or if it failed to delete the memory,
    // the compilation would fail.
    return true; 
}

// Forces constant evaluation
static_assert(evaluate_destruction());

Triviality and Literal Types

Declaring a destructor constexpr does not inherently make it non-trivial. A constexpr destructor can still be trivial (for example, if it is implicitly generated or explicitly defaulted via constexpr ~T() = default;). The constexpr specifier simply allows a destructor to contain executable logic (making it non-trivial) while remaining valid for execution during the translation phase. In C++20, having a constexpr destructor is a necessary condition for a class to be classified as a literal type. Prior to C++20, literal types strictly required trivial destructors. However, a constexpr destructor is not a sufficient condition on its own. To be a literal type, the class must still satisfy all other literal type requirements, including:
  • Having at least one constexpr constructor (that is not a copy or move constructor).
  • Ensuring all base classes are literal types.
  • Ensuring all non-static data members are literal types.
Master C++ with Deep Grasping Methodology!Learn More