Every C++ class has a well-defined lifecycle—creation, usage, and destruction. Two core mechanisms govern this process: constructors and destructors. These special member functions ensure proper initialization and cleanup, forming the foundation of safe resource management in object-oriented C++.

The Six Special Member Functions

When no user-defined members are present, the compiler implicitly declares six special member functions. Among them, constructors and destructors are the most critical for managing object state and resources:

• Constructor: Initializes an object’s state upon creation.
• Destructor: Releases resources before an object is destroyed.
• Copy constructor
• Copy assignment operator
• Move constructor (C++11+)
• Move assignment operator (C++11+)

Note: While older references list "address-of operators" as part of the original six, modern C++ standards emphasize move semantics instead. This article focuses on the two most essential: construction and destruction.

Constructors: Controlled Initialization

A constructor is a member function with the same name as its class and no return type—not even void. It executes automatically when an object is instantiated and cannot be called explicitly.

Key Characteristics

1. Name matches class name.
2. No return type—not even void.
3. Automatically invoked during object creation; manual invocation is ill-formed.
4. Overloadable: Multiple constructors with distinct parameter signatures enable flexible initialization.
5. Default generation: If no constructor is declared, the compiler synthesizes a public, trivial, default constructor—unless any user-defined constructor exists.

Example: Overloaded Constructors

class Clock {
public:
    // Default constructor
    Clock() : hour_(12), minute_(0), second_(0) {}

    // Parameterized constructor
    Clock(int h, int m, int s) 
        : hour_(h % 24), minute_(m % 60), second_(s % 60) {}

    // Single-parameter constructor (defaults others)
    explicit Clock(int h) : hour_(h % 24), minute_(0), second_(0) {}

    void display() const {
        std::cout << hour_ << ":" << minute_ << ":" << second_ << "\n";
    }

private:
    int hour_, minute_, second_;
};

int main() {
    Clock c1;           // Uses default constructor
    Clock c2(9, 30, 45); // Uses parameterized constructor
    Clock c3(15);       // Uses single-parameter constructor
    c1.display(); c2.display(); c3.display();
}

Member Initialization vs. Assignment

Inside a constructor body, statements like hour_ = h; perform assignment, not initialization. True initialization occurs only once—and must happen before the constructor body runs. That’s where the member initializer list comes in.

Member Initializer List Syntax

Clock(int h, int m, int s) 
    : hour_(h % 24), minute_(m % 60), second_(s % 60) {
    // Constructor body (optional)
}

This syntax ensures each member is initialized directly—not assigned afterward—improving efficiency and enabling initialization of non-modifiable members.

When Initializer Lists Are Mandatory

You must use the initializer list for:

• const data members
• Reference members
• Members of classes without default consturctors

class Sensor {
public:
    Sensor(double scale) : scaling_factor_(scale) {}
private:
    const double scaling_factor_; // Must be initialized in list
};

class Device {
public:
    Device(const Sensor& s) 
        : sensor_ref_(s), id_counter_(next_id_++) {}
    
private:
    const Sensor& sensor_ref_; // Reference → requires init list
    static inline int next_id_ = 0;
    int id_counter_;
};

Declaration Order Dictates Initialization Order

Members are initialized in the order they’re declared in the class—not the order listed in the initializer. Mismatched ordering can lead to undefined behavior if later members depend on earlier ones that haven’t yet been initialized.

class BadOrder {
    int y_;
    int x_; // Declared after y_, so initialized second
public:
    BadOrder(int val) : x_(val), y_(x_ * 2) {} // y_ uses uninitialized x_
};

Here, y_ reads x_ before it's initialized—resulting in garbage. Always declare dependent members first.

Destructors: Safe Resource Cleanup

A destructor is a special member named with a tilde (~) prefix followed by the class name. It takes no parameters and returns no value. It’s invoked automatically when an object goes out of scope or is explicitly deleted.

Core Rules

• Exactly one destructor per class; no overloading allowed.
• If omitted, the compiler generates a trivial destructor.
• Compiler-generated destructors call destructors of member objects (including base classes) but perform no action on built-in types (e.g., int, double, raw pointers).

When to Define a Custom Destructor

Write a destructor only when your class manages external resources—such as heap memory, file handles, or network sockets. Built-in types require no manual cleanup; their storage is reclaimed automatically.

class DynamicBuffer {
public:
    DynamicBuffer(size_t size) : capacity_(size), buffer_(new char[size]) {}

    ~DynamicBuffer() {
        delete[] buffer_; // Critical: release allocated memory
        buffer_ = nullptr;
    }

    // Rule of Three/Five would also require copy/move ops here

private:
    size_t capacity_;
    char* buffer_;
};

Compiler-Generated Behavior Recap

The synthesized destructor recursively invokes destructors for all non-static data members and base classes—but does nothing for fundamental types. This is intentional: raw integers or floats have no cleanup logic. However, if a member is of a custom type (e.g., std::string, std::vector, or your own class), its destructor will be called automatically.

Stack Example Revisited

Consider a simplified stack implementation:

class SimpleStack {
    int* elements_;
    size_t top_;
    size_t capacity_;

public:
    SimpleStack(size_t cap = 16) 
        : capacity_(cap), top_(0), elements_(new int[cap]) {}

    ~SimpleStack() {
        delete[] elements_; // Prevents memory leak
    }

    void push(int value) {
        if (top_ == capacity_) {
            // Reallocation logic would go here
        }
        elements_[top_++] = value;
    }
};

Without the destructor, every SimpleStack instance would leak memory. With it, cleanup happens reliably—even during exception propagation.