Destructor in C++: what it is and when it runs

A destructor in C++ is the member function that runs automatically when an object’s life ends: ~File() for a class named File. It takes no arguments and returns nothing, and its job is to release what the object owns. A local object’s destructor runs when execution leaves the block it was created in, usually at its closing brace.

Tracer, the example used all the way through, is a struct whose destructor prints the object’s name, so each sample shows the moment it ran:

#include <iostream>
#include <string>

struct Tracer {
    std::string name;
    ~Tracer() { std::cout << "~" << name << '\n'; }  // the destructor
};

int main() {
    {
        Tracer local{"local"};
        std::cout << "before the closing brace\n";
    }  // local's life ends here: its destructor runs
    std::cout << "after the closing brace\n";
}

It printed:

before the closing brace
~local
after the closing brace

Nothing in main calls ~Tracer(). The destructor ran at the inner block’s closing brace, between the two lines.

The samples are C++17, built with MSVC 19.44, Clang 19.1 (MSVC STL), GCC 16.2 and Clang 23.1 (libc++). All four printed the same lines, apart from the one difference shown under the vector below. Since When lists which compiler releases support each standard.

When is a destructor called?

A destructor is called when its object’s life ends, and when that happens depends on how the object was made:

Three of those cases in one program:

int main() {
    Tracer* heap = nullptr;
    {
        Tracer local{"local"};
        heap = new Tracer{"heap"};
        std::cout << "closing the block\n";
    }  // ~local runs here; heap's object lives on
    std::cout << "after the block\n";
    delete heap;  // ~heap runs here, and only here

    {
        std::vector<Tracer> names(2);  // two elements, made in place
        names[0].name = "names[0]";
        names[1].name = "names[1]";
        std::cout << "closing the vector's block\n";
    }  // the vector is destroyed, and with it both elements
    std::cout << "end of main\n";
}

Microsoft’s library (under MSVC and Clang 19.1) and GCC’s libstdc++ printed:

closing the block
~local
after the block
~heap
closing the vector's block
~names[0]
~names[1]
end of main

~heap waited for the delete, after its block had closed. libc++ printed the same lines, except that it destroyed names[1] before names[0]: the order in which a container destroys its elements is the library’s choice, so do not write code that depends on it.

Globals and static objects outlive main:

Tracer global{"global"};  // made before main starts

void helper() {
    static Tracer kept{"static"};  // made on the first call
}

int main() {
    helper();
    Tracer local{"local"};
    std::cout << "last line of main\n";
}  // ~local here; ~static and ~global after main returns

It printed:

last line of main
~local
~static
~global

Objects that live for the whole run, globals and static locals, are destroyed after main returns ([basic.start.term]). kept, made after global, was destroyed before it.

In what order are objects destroyed?

Locals in one block, the parts of one object, and globals and statics are destroyed in the reverse of the order they were created. Two locals made as a, then b, are destroyed b first. Inside one object, the destructor’s body runs first, then the members in the reverse of the order they are declared, then the base class (destruction sequence):

void two_locals() {
    Tracer a{"a"};
    Tracer b{"b"};
}  // ~b, then ~a: the reverse of the order they were made

struct Base {
    ~Base() { std::cout << "~Base\n"; }
};

struct Report : Base {
    Tracer first{"first"};    // declared first
    Tracer second{"second"};  // declared second
    ~Report() { std::cout << "~Report body\n"; }
};

int main() {
    two_locals();
    std::cout << "--\n";
    {
        Report report;
    }  // ~Report body, ~second, ~first, ~Base
}

It printed:

~b
~a
--
~Report body
~second
~first
~Base

Report inherits from Base and has two members, first and second. The figure draws such an object as four rows, the base class on top. Building it runs down the rows: the base class first, then the members in the order they are declared, then the constructor’s body (initialization order). Destroying it runs back up.

Because the body runs before any member is destroyed, a destructor can still use every member of its class. C++ constructors cover the building half.

What is a destructor for?

A destructor gives back what the object holds: it closes a file, releases a lock, frees memory. It runs on every way out of a block, an early return and a caught exception included, so the cleanup cannot be forgotten. Here Tracer stands in for an open file:

bool save(bool disk_full) {
    Tracer file{"save.txt"};
    if (disk_full) {
        std::cout << "disk full, returning early\n";
        return false;  // ~save.txt runs on the way out
    }
    std::cout << "saved\n";
    return true;
}

void load() {
    Tracer file{"load.txt"};
    std::cout << "throwing\n";
    throw std::runtime_error("load failed");  // ~load.txt runs too
}

int main() {
    save(true);
    try {
        load();
    } catch (const std::runtime_error& e) {
        std::cout << "caught: " << e.what() << '\n';
    }
}

It printed:

disk full, returning early
~save.txt
throwing
~load.txt
caught: load failed

~save.txt printed on the early return, and ~load.txt before the catch block ran. Tying a resource to the life of an object this way is called RAII, short for resource acquisition is initialization (RAII on cppreference).

Do you need to write a destructor?

Usually not. Members such as std::string, std::vector and std::unique_ptr clean up after themselves, and the destructor the compiler writes for your class runs theirs:

struct Player {
    std::string name = "Ada";
    std::vector<int> scores{10, 20, 30};
    Tracer tracer{"tracer"};
    // No destructor written: the compiler's own one destroys
    // tracer, scores and name, in that order.
};

int main() {
    {
        Player player;
        std::cout << player.name << " has " << player.scores.size()
                  << " scores\n";
    }  // ~tracer: the member's destructor still runs
    std::cout << "after the block\n";
}

It printed:

Ada has 3 scores
~tracer
after the block

Leaving the destructor, the copies and the moves to the compiler is the rule of zero. Write a destructor only when the class itself holds something no member cleans up, such as an integer handle from a C library; a pointer from new belongs in a std::unique_ptr member (C++ Core Guidelines C.30). Such a class then needs its copy and move operations defined or deleted too (C.21), which the rule of zero article walks through.

What is a virtual destructor?

A virtual destructor is a base class’s destructor declared virtual, so that delete through a pointer to the base runs the derived class’s destructor too. Without it, that delete is undefined behavior: the standard sets no rule for what the program does ([expr.delete]). A base class whose objects are deleted that way needs one, and = default is enough:

struct Base {
    virtual ~Base() = default;
};

struct Derived : Base {
    ~Derived() override { std::cout << "~Derived\n"; }
};

int main() {
    Base* raw = new Derived;
    delete raw;  // ~Derived runs, then Base's destructor

    std::unique_ptr<Base> owned = std::make_unique<Derived>();
    std::cout << "end of main\n";
}  // owned deletes its Derived: ~Derived again

It printed:

~Derived
end of main
~Derived

Polymorphism in C++ has the longer version, with a base class whose destructor prints too.

Common destructor mistakes

• Calling local.~Tracer() yourself on a local: the destructor runs again at the closing brace, and that second call is undefined behavior (destructors on cppreference).
• Forgetting delete: an object made with new lives until delete is called on it, so its destructor never runs (new expression on cppreference). Hold it in a std::unique_ptr, which calls delete for you.
• Calling delete twice on the same pointer: after the first, it no longer points to an object made by new, so the second is undefined behavior (delete on cppreference).
• Letting an exception leave a destructor. Destructors are noexcept unless you say otherwise, so an exception that leaves one calls std::terminate, which ends the program ([except.terminate]); can a C++ destructor throw? has the rest.

The Language section has the other answers on classes and objects.