Destructor

Programming Language & Its Applications — C++ Constructs with Objects and Classes, NEC licence examination syllabus (Nepal Engineering Council).

Destructors

The function that runs automatically when an object dies — and the other half of RAII.

🌍 Where this lives: destructors are why well-written C++ needs no finally block and no garbage collector. A std::lock_guard locks a mutex in its constructor and unlocks it in its destructor, so the lock is released even if an exception is thrown mid-function — something a Java synchronized block also gives you, but C++ generalises it to every resource: files, sockets, database transactions, GPU buffers. Python's with statement is the same idea done explicitly; C++ makes it automatic. Search "RAII lock_guard exception safety" to see why this pattern eliminated an entire family of resource-leak bugs.

Definition and rules

class File { FILE *fp; public: File(const char *n) { fp = fopen(n, "r"); } ~File() { if (fp) fclose(fp); } ← DESTRUCTOR }; RULES — a destructor: · has the class name prefixed with ~ (tilde) · takes NO parameters · has NO return type · cannot be overloaded — there is exactly ONE per class · cannot be const, static, or volatile · is called AUTOMATICALLY; you normally never call it · may be virtual (essential for base classes — see the virtual-functions section) If you write none, the compiler generates a trivial one that destroys each member. That is correct for classes holding values; it is a leak for classes holding raw resources. WHEN IT RUNS: · a local object → at the closing brace of its scope · a temporary → at the end of the full expression · a member → when the containing object dies · a heap object → when you call delete · a global/static → after main returns · during an exception → as the stack unwinds (this is the key to exception safety)

lifetime.cpp

#include <iostream>
#include <string>

class Tracer {
    std::string name;
public:
    Tracer(std::string n) : name(std::move(n)) {
        std::cout << "  + " << name << " born\n";
    }
    ~Tracer() { std::cout << "  - " << name << " dies\n"; }
};

Tracer global("global");

void func() {
    std::cout << " enter func\n";
    Tracer local("local");
    {
        Tracer inner("inner-block");
    }                       /* inner dies HERE */
    std::cout << " leave func\n";
}                           /* local dies HERE */

int main() {
    std::cout << "main starts\n";
    func();

    Tracer *heap = new Tracer("heap");
    std::cout << "before delete\n";
    delete heap;            /* dies exactly here */

    Tracer a("a"), b("b"), c("c");
    std::cout << "main ends\n";
    return 0;               /* c, b, a — REVERSE order */
}
Output:
  + global born
main starts
 enter func
  + local born
  + inner-block born
  - inner-block dies
 leave func
  - local dies
  + heap born
before delete
  - heap dies
  + a born
  + b born
  + c born
main ends
  - c dies
  - b dies
  - a dies
  - global dies

Two orderings to notice: 1. LIFO within a scope. a, b, c were constructed in that order and destroyed c, b, a. This matters because a later object may depend on an earlier one — destroying in reverse guarantees dependencies outlive their users. 2. Globals are constructed before main and destroyed after it. So "global dies" is the very last line — after "main ends" and after every local. The construction/destruction symmetry is exact: construction order = A, B, C destruction order = C, B, A This holds for locals, for members within an object, and for base classes in an inheritance chain.

Worked example — RAII, the whole point

raii.cpp

#include <iostream>
#include <cstdio>
#include <stdexcept>

/* THE MANUAL WAY — every exit path must release */
void manual_bad(bool fail) {
    FILE *fp = std::fopen("data.txt", "w");
    if (!fp) return;
    std::fprintf(fp, "some work\n");

    if (fail) {
        /* forgot fclose -> LEAK. And if we THROW instead
           of returning, fclose is skipped even if written. */
        throw std::runtime_error("failed mid-way");
    }
    std::fclose(fp);
}

/* THE RAII WAY — the destructor cannot be skipped */
class FileGuard {
    FILE *fp;
public:
    FileGuard(const char *name, const char *mode)
        : fp(std::fopen(name, mode)) {
        if (!fp) throw std::runtime_error("cannot open");
        std::cout << "  opened\n";
    }
    ~FileGuard() { if (fp) { std::fclose(fp);
                   std::cout << "  closed\n"; } }

    /* a resource holder must not be copied naively */
    FileGuard(const FileGuard&)            = delete;
    FileGuard& operator=(const FileGuard&) = delete;

    FILE *get() { return fp; }
};

void raii_good(bool fail) {
    FileGuard f("data.txt", "w");
    std::fprintf(f.get(), "some work\n");
    if (fail) throw std::runtime_error("failed mid-way");
    std::cout << "  finished normally\n";
}

int main() {
    std::cout << "normal path:\n";
    raii_good(false);

    std::cout << "exception path:\n";
    try { raii_good(true); }
    catch (const std::exception &e) {
        std::cout << "  caught: " << e.what() << "\n";
    }
    return 0;
}
Output:
normal path:
  opened
  finished normally
  closed
exception path:
  opened
  closed              <-- destructor ran during unwinding
  caught: failed mid-way

Look at the exception path output order: opened closed ← the destructor ran BEFORE the catch block caught: ... That is STACK UNWINDING. When the throw happens, C++ walks back out of every scope between the throw and the matching catch, running the destructor of every fully-constructed local object on the way. The file is closed automatically, with no cleanup code at the throw site. Compare the amount of code needed: manual : one fclose per exit path (return, break, throw, and every early return you add later) RAII : one destructor, written once For a function with 6 early returns and 3 possible throws, the manual version needs cleanup in 9 places and misses one the day someone adds a tenth. The RAII version needs zero. This is why the C++ standard library has NO close(), unlock(), or free() that you are expected to call. You get std::fstream, std::lock_guard, std::unique_ptr — all of which release in their destructor.

The = delete on the copy constructor is not decoration. A FileGuard copied naively would have two objects holding the same FILE*, and both destructors would fclose it — a double-close, the same shape of bug as double-free. Deleting the copy operations makes the mistake a compile error instead of a runtime crash.

Constructor/destructor order with members

member_order.cpp

#include <iostream>

class Part {
    const char *n;
public:
    Part(const char *name) : n(name) {
        std::cout << "    +Part " << n << "\n";
    }
    ~Part() { std::cout << "    -Part " << n << "\n"; }
};

class Engine {
    Part block{"block"};      /* declared 1st */
    Part piston{"piston"};    /* declared 2nd */
    Part valve{"valve"};      /* declared 3rd */
public:
    Engine()  { std::cout << "  +Engine body\n"; }
    ~Engine() { std::cout << "  -Engine body\n"; }
};

int main() {
    std::cout << "creating Engine:\n";
    { Engine e; std::cout << "  ...using engine...\n"; }
    std::cout << "done\n";
    return 0;
}
Output:
creating Engine:
    +Part block
    +Part piston
    +Part valve
  +Engine body
  ...using engine...
  -Engine body
    -Part valve
    -Part piston
    -Part block
done

The exact sequence, and why it must be this way: CONSTRUCTION 1. base class constructors (if any) 2. MEMBERS, in DECLARATION order 3. the constructor BODY runs last → by the time your body executes, every member is already a valid object. That is the guarantee. DESTRUCTION — exactly reversed 1. the destructor BODY runs first → your cleanup code can still use every member 2. MEMBERS, in reverse declaration order 3. base class destructors Both halves of that ordering are deliberate. Construction puts members first so the body can use them; destruction runs the body first so it can still use them. Neither would work the other way round.

Common destructor mistakes

1. FORGETTING delete[] FOR ARRAYS int *a = new int[100]; delete a; ✗ undefined behaviour delete[] a; ✔ For an array of objects, delete (without []) calls only ONE destructor instead of 100. 2. DOUBLE DELETE delete p; delete p; ✗ heap corruption Fix: set p = nullptr after delete (deleting nullptr is a legal no-op), or use unique_ptr. 3. NON-VIRTUAL BASE DESTRUCTOR Base *p = new Derived(); delete p; ✗ only ~Base() runs; ~Derived() is SKIPPED → leak Fix: virtual ~Base(). Any class meant to be inherited from needs a virtual destructor. 4. THROWING FROM A DESTRUCTOR ~Bad() { throw std::runtime_error("no"); } If this happens during stack unwinding from another exception, the program calls std::terminate. Destructors must not throw — catch and swallow internally. 5. FORGETTING THE DESTRUCTOR ENTIRELY when the class holds a raw pointer → a leak on every object.

mistakes.cpp

#include <iostream>
#include <memory>

class Node { public: ~Node() { std::cout << "~Node "; } };

int main() {
    /* delete[] calls EVERY destructor */
    Node *arr = new Node[3];
    std::cout << "delete[]: ";
    delete[] arr;
    std::cout << "\n";

    /* safe delete idiom */
    Node *p = new Node;
    std::cout << "delete p: ";
    delete p; p = nullptr;
    delete p;               /* legal no-op on nullptr */
    std::cout << "\n";

    /* the modern answer: no delete at all */
    { auto up = std::make_unique<Node>();
      std::cout << "unique_ptr scope end: "; }
    std::cout << "\n";
    return 0;
}
Output:
delete[]: ~Node ~Node ~Node
delete p: ~Node
unique_ptr scope end: ~Node

Three destructor calls from delete[] — with plain delete you would see one, and the other two objects would never be destroyed. For int that leaks nothing visible; for objects holding files or memory, it leaks everything they own.

🌍 Go further: the deeper reason RAII matters is that it makes cleanup compositional. An object holding three RAII members needs no destructor at all — each member cleans itself up, so correctness composes automatically as the program grows. This is exactly what garbage-collected languages give up: a GC handles memory but not files, locks, or sockets, which is why Java needed try-with-resources and C# needed using bolted on later. Search "why C++ does not need a garbage collector" and "deterministic destruction" — the argument is stronger than it first sounds.

💡 Exam angle: state the destructor's rules (name with ~, no parameters, no return type, exactly one per class, cannot be overloaded) and list when it is called for locals, temporaries, heap objects and globals. The construction/destruction order — members in declaration order, destroyed in reverse, body last on the way in and first on the way out — is a favourite trace question. Know the five common mistakes, especially delete versus delete[] and the non-virtual base destructor leak.

Syllabus points

Destructor purpose & order

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.