24. The Destructor

Advanced perspective: destruction is the final ownership decision

A destructor is correct when lifetime ends without leaving ownership unfinished

The C++ term is destructor, not deconstructor. A destructor is a special member function that participates in ending an object's lifetime and performing the teardown required by its type. It does not reverse the constructor statement by statement. It also does not mean that every class should contain a hand-written cleanup body.

The easy proxy is to look for delete, close or release inside ~ClassName(). That proves only that a function has been called. The real criterion is ownership: every acquired resource has one responsible owner, copying and moving preserve that responsibility, partial construction remains safe, and every ordinary lifetime path reaches the appropriate release exactly once.

Start with an observable lifetime, not a raw allocation

#include <iostream>
#include <string>
#include <utility>

class Trace {
public:
    explicit Trace(std::string name) : name_{std::move(name)} {
        std::cout << "construct " << name_ << '\n';
    }

    ~Trace() {
        std::cout << "destroy " << name_ << '\n';
    }

private:
    std::string name_;
};

int main() {
    Trace first{"first"};
    Trace second{"second"};
}

The program produces four lines:

construct first
construct second
destroy second
destroy first

first completes construction before second. When the block exits, the constructed automatic objects are destroyed in reverse order. The output is evidence for this execution, not a decorative slogan: each construction has one corresponding destruction, and the later object disappears before the earlier object on which it might depend.

A destructor body is only the first visible step of structural teardown

For a complete derived object, the most-derived destructor body runs while its members and base subobjects are still available. Then non-static data members are destroyed in reverse declaration order, followed by direct base subobjects in reverse construction order; virtual bases are destroyed as part of the complete object's final base teardown. Array elements are likewise destroyed in reverse construction order.

The member-initialiser list cannot change member declaration order. If a member named writer uses a member named file during destruction, their declaration order must make that dependency safe. A clever-looking initialiser order does not renegotiate the class layout or its destruction sequence.

Object lifetime and storage are connected, but they are not the same thing

An automatic object's destructor runs when its block exits normally or through stack unwinding. Its storage belongs to the automatic-storage mechanism. For the usual dynamic-allocation path, a delete-expression requests both destruction of the object and release of the allocation; those remain separate responsibilities even though one expression initiates both. A destructor can release a file or mutex without deallocating the storage occupied by the owning object.

This distinction removes two common errors. First, delete operates on an appropriate pointer expression, not a reference. Secondly, calling a destructor is not a general replacement for delete, because an explicit destructor call does not by itself establish the matching storage-deallocation policy. Most application code should express ownership through established RAII types rather than manage either step explicitly.

Partial construction is already an ownership test

If a constructor exits by throwing, the complete object's destructor is not called because that complete object was never successfully constructed. Subobjects whose construction completed are destroyed in reverse completion order. A raw resource acquired between subobject construction and the throw can therefore leak unless it has already been placed under an owner.

This is one of RAII's strongest consequences. Store a file, allocation, lock or handle in a member whose own construction establishes ownership. If a later member fails, the earlier owner is destroyed automatically during unwinding. The containing class does not need to guess how far its constructor progressed, and a destructor for an object that never existed is not asked to repair the situation.

Rule of Zero is the default; the other rules are ownership reviews

If members and bases already express the correct resource semantics, allow their special members to compose. That is the Rule of Zero. It does not promise that every operation exists. A std::unique_ptr member normally makes copying unavailable while allowing exclusive ownership to move. A std::string or std::vector normally supports value copying. The generated interface follows the members' capabilities.

If a type directly manages a raw resource, a custom destructor raises the Rule-of-Three questions about copy construction and copy assignment. Move construction and move assignment add the Rule-of-Five questions. A user-declared destructor also prevents the usual implicit declaration of a move constructor, so adding an apparently harmless destructor can make an rvalue copy instead or make the operation unavailable. The rule names are prompts to inspect the complete ownership interface, not quotas for boilerplate.

Polymorphic destruction is a base-interface policy

If clients may destroy a derived object through a pointer to its base, the base needs a public virtual destructor. This applies equally when an owning smart pointer stores a Base* and its ordinary deleter eventually performs that deletion. Virtual dispatch then reaches the derived destructor before the base subobject is destroyed.

There is a second coherent policy: make the base destructor protected and non-virtual when destruction through a base pointer is deliberately forbidden. The access control prevents clients from making the invalid request. A public non-virtual destructor on a polymorphic base offers an operation that cannot safely complete the derived lifetime. Merely adding another virtual member function does not fix that contradiction.

Cleanup failure needs a policy before the destructor begins

A destructor with no explicit exception specification derives that specification from the destructors of its potentially constructed subobjects and, where relevant, virtual bases. It is therefore inaccurate to say that a destructor is non-throwing simply because its body contains no written throw. The members participate in the rule.

Nevertheless, ownership destructors should be designed not to let exceptions escape. If a non-throwing destructor exits through an exception, the program terminates. If a destructor directly invoked during stack unwinding throws, termination also follows because another exception is already being handled. Catching and ignoring every failure is not automatically correct either.

If a release operation can fail and the caller must react, expose an explicit operation such as close() that reports the result while normal error handling remains possible. The destructor can provide a non-throwing fallback and preserve process-local safety, but it cannot promise that an external transaction was committed merely because the C++ object went out of scope.

Deterministic destruction is an ordinary-path guarantee, not an immortality policy

A destructor is therefore the right place for process-local resource release, not the sole durability mechanism for persistent data. Files may still require flush, sync, commit, journalling or an application protocol. Power loss does not consult the class definition.

Transfer task: design the end of a resource-owning session

Design a Session that owns a log file, a network connection and a temporary receive buffer. Construction may fail after any acquisition. Closing the network connection may report an error that the caller needs to see, while releasing the buffer cannot fail. Decide which existing RAII members should represent the resources and in which declaration order they belong. State whether Session is copyable, movable or neither.

Trace successful construction, failure after each completed member, an early return, an exception during use, an explicit successful close(), a failed close(), and destruction of both sides after a move. If a base interface owns sessions polymorphically, choose and justify either public virtual destruction or protected non-virtual destruction. The result is complete only when every trace releases each acquired resource once and every reportable failure still has a route to the caller.

#include <cstddef>
#include <filesystem>
#include <fstream>
#include <string_view>
#include <system_error>
#include <vector>

class Connection {
public:
    static Connection connect(std::string_view endpoint); // throws on failure

    Connection(const Connection&) = delete;
    Connection& operator=(const Connection&) = delete;
    Connection(Connection&&) noexcept;
    Connection& operator=(Connection&&) = delete;

    ~Connection() noexcept; // best-effort release if still owning

    [[nodiscard]] std::error_code close() noexcept;
    [[nodiscard]] bool is_open() const noexcept;
};

class Session {
public:
    Session(const std::filesystem::path& log_path,
            std::string_view endpoint,
            std::size_t buffer_size);

    Session(const Session&) = delete;
    Session& operator=(const Session&) = delete;
    Session(Session&&) = default;
    Session& operator=(Session&&) = delete;

    ~Session() = default;

    [[nodiscard]] std::error_code close() noexcept {
        return connection_.close();
    }

private:
    static std::ofstream open_log(const std::filesystem::path& path);

    std::ofstream log_;                 // constructed first, destroyed last
    Connection connection_;             // constructed second
    std::vector<std::byte> buffer_;     // constructed last, destroyed first
};

class ISession {
public:
    virtual ~ISession() = default;
    [[nodiscard]] virtual std::error_code close() noexcept = 0;
};

Destruction completes the course's treatment of state, scope, ownership and behaviour. The final function in an object's life should contain no surprises because the ownership policy was decided when the type was designed. When that policy is expressed by members, the best custom destructor is often the one you never needed to write.