Destructor — RAII principle: Exercises — Coding deep dive

Quick vocabulary refresher, so no symbol appears unearned:

Definition Words we will use

Resource — anything you must give back: heap memory, a file handle, a lock. Grabbed once, must be released once.
Constructor ClassName(...) — runs when an object is born; the natural place to grab a resource. See Constructor — initialization.
Destructor ~ClassName() — runs automatically when an object dies; the place to release. No parameters, no return type, one per class.
Pointer — a variable that stores a memory address (a number saying "the thing lives over there"). Pointee — the actual object living at that address. Destroying a pointer throws away the address slip; it does not touch the pointee.
Scope — the region between { and its matching }. A local object dies when control leaves its scope.
Temporary — an unnamed object the compiler creates mid-expression (e.g. the result of a + b or std::string("hi")). It is destroyed at the end of the full expression — the ; — not at the end of the block.
Stack unwinding — when an exception is thrown, C++ walks back up the call stack destroying every fully-built local object on the way. See Exception Safety & Stack Unwinding.
LIFO — "Last In, First Out": the last object born is the first to die.
noexcept — a promise on a function that it will not let an exception escape. Destructors are noexcept by default, and for a very good reason (see L4).

Level 1 — Recognition

Can you spot the rule?

Recall Solution 1.1

Valid: (a) and (d).

(a) correct declaration: name ~Box, no parameters, no return type. ✅
(b) ✗ — a destructor takes no parameters.
(c) ✗ — a destructor has no return type, not even void.
(d) ✅ — this is the out-of-class definition of the same destructor. Why: the standard fixes the destructor's signature exactly; you only get to write its body.

Recall Solution 1.2

False. There is exactly one destructor per class. Since it takes no parameters, there is nothing to overload on. (Contrast with constructors, which can be overloaded because they take arguments.)

Worked example Exercise 1.3

Match each event to whether it triggers a destructor call:

Event	Destructor runs?
A local object reaches its closing `}`	?
`delete p;` on a heap pointer	?
A raw pointer `p` goes out of scope (no `delete`)	?
A temporary `std::string("hi")` at the `;`	?
`main` ends, destroying a global object	?

Recall Solution 1.3

Event	Destructor runs?
Local object reaches `}`	Yes
`delete p;`	Yes (destroys the pointee — the object at the address, defined above)
Raw pointer goes out of scope	No — the pointer (the address slip) dies, but the pointee it names is untouched → leak
Temporary at the `;`	Yes — a temporary is destroyed at the end of the full expression, i.e. at the `;`, not at the block's `}`
Global object at program end	Yes
Why the third is No: a raw pointer is just a number holding an address. Destroying the number does nothing to the memory it pointed at. That is exactly the hole RAII plugs.
Why the temporary is Yes and early: the compiler builds it, uses it within the expression, then destroys it immediately at the `;`. This is why `std::lock_guard<std::mutex>(m);` (an unnamed temporary!) is a bug — it locks and instantly unlocks at the `;`, protecting nothing. You must give it a name.

Level 2 — Application

Predict the output.

Worked example Exercise 2.1

struct Loud {
    char id;
    Loud(char c): id(c) { std::cout << "+" << id << " "; }
    ~Loud()          { std::cout << "-" << id << " "; }
};
void run() { Loud a('a'); Loud b('b'); Loud c('c'); }

What does run() print?

Recall Solution 2.1

+a +b +c -c -b -a Construction is top-to-bottom: a, then b, then c. Destruction is LIFO — reverse order — so c dies first, then b, then a. Read the figure below: it draws the three objects as a stack of chalk boxes. The white arrow on the left shows construction pushing a, b, c upward (bottom to top); the pink arrow on the right shows destruction popping from the top down — c first (top, dies first), a last (bottom, dies last). That top-off-first motion is LIFO — a stack of plates: the last plate on is the first plate off.

Worked example Exercise 2.2

struct Loud { char id; Loud(char c):id(c){std::cout<<"+"<<id<<" ";}
                       ~Loud(){std::cout<<"-"<<id<<" ";} };
void run() {
    Loud a('a');
    { Loud b('b'); }      // inner scope
    Loud c('c');
}

Output?

Recall Solution 2.2

+a +b -b +c -c -a b lives only inside the inner { }, so it is destroyed before c is even built. Then at the outer }, the survivors c and a die LIFO: c first, a last. Lesson: destruction is driven by scope exit, not by declaration order alone.

Worked example Exercise 2.3

struct Loud { char id; Loud(char c):id(c){std::cout<<"+"<<id<<" ";}
                       ~Loud(){std::cout<<"-"<<id<<" ";} };
void run() {
    Loud* p = new Loud('h');   // heap
    Loud s('s');               // stack
}   // what is printed, and is there a bug?

Recall Solution 2.3

Prints +h +s -s — and there is a memory leak. s is destroyed at } (prints -s). But p is a raw pointer; leaving scope destroys the pointer, not the Loud pointee on the heap. No delete p; ⇒ ~Loud for 'h' never runs ⇒ -h never prints ⇒ leak. Fix: delete p; before }, or use std::unique_ptr<Loud>.

Level 3 — Analysis

Find the bug and explain the mechanism.

Worked example Exercise 3.1 — the shallow-copy time bomb

class Buf {
    int* d;
public:
    Buf(int n): d(new int[n]) {}
    ~Buf() { delete[] d; }
};
void run() {
    Buf a(10);
    Buf b = a;   // (!)
}

What undefined behaviour occurs, and why? Name the rule that fixes it.

Recall Solution 3.1

Double delete[] → undefined behaviour (likely crash). Buf b = a; uses the compiler-generated copy constructor, which does a shallow copy: it copies the pointer value d, so a.d and b.d point to the same buffer. Read the figure below: the blue box a.d and the pink box b.d are two separate pointer variables, but both chalk arrows land on the same yellow "heap buffer int[10]" — they alias it. At }, both destructors run: ~a does delete[] and frees the buffer; ~b then does delete[] on that same, already-freed buffer — the double free the caption warns about.

Fix — the Rule of Three: because you wrote a destructor that owns a raw resource, you must also write a copy constructor and copy assignment (doing a deep copy), or delete them. Best of all: follow Rule of Zero — store a std::vector<int> and write no destructor at all.

Worked example Exercise 3.2 — the missing

virtual

struct Base            { ~Base() { std::cout << "~Base "; } };
struct Derived : Base  { int* buf = new int[100];
                         ~Derived(){ delete[] buf; std::cout << "~Derived "; } };
Base* p = new Derived();
delete p;

What prints, and what leaks?

Recall Solution 3.2

Prints ~Base only — buf leaks. delete p; looks at p's static type Base*. Because ~Base is not virtual, the call is resolved at compile time to ~Base alone; ~Derived never runs, so delete[] buf never happens. Fix: make the base destructor virtual: virtual ~Base(). Then delete p; dispatches at runtime to ~Derived first (frees buf), then ~Base. With the fix the output is ~Derived ~Base . See Virtual Functions & Polymorphism.

Worked example Exercise 3.3 — member vs base order

struct M { char t; M(char c):t(c){} ~M(){ std::cout<<"~M"<<t<<" "; } };
struct Base { ~Base(){ std::cout<<"~Base "; } };
struct D : Base {
    M m1{'1'}, m2{'2'};
    ~D(){ std::cout<<"~Dbody "; }
};
D d;   // then it goes out of scope

In what order do the messages print?

Recall Solution 3.3

~Dbody ~M2 ~M1 ~Base Destruction of one object goes: (1) the derived destructor body runs first (~Dbody), then (2) members in reverse declaration order — m2 before m1 — then (3) the base class destructor (~Base). It is LIFO applied inside a single object: the base was built first, so it dies last.

Level 4 — Synthesis

Design correct RAII code.

Recall Solution 4.1

class FileGuard {
    FILE* f;
public:
    explicit FileGuard(const char* path)          // ACQUIRE
        : f(std::fopen(path, "r")) {
        if (!f) throw std::runtime_error("open failed");
    }
    ~FileGuard() noexcept {                        // RELEASE — always, never throws
        if (f) std::fclose(f);
    }
    FileGuard(const FileGuard&)            = delete;  // forbid copy (no two owners of one handle)
    FileGuard& operator=(const FileGuard&) = delete;
    FileGuard(FileGuard&& o) noexcept : f(o.f) { o.f = nullptr; } // MOVE: steal + null out source
    FileGuard& operator=(FileGuard&& o) noexcept {                // move-assign: close mine, steal
        if (this != &o) { if (f) std::fclose(f); f = o.f; o.f = nullptr; }
        return *this;
    }
    FILE* get() const { return f; }
};

Why each piece:

Acquire in the constructor; throw if it fails, so a FileGuard never holds a broken handle.
Release in the destructor, guarded by if (f) (the handle may have been moved-from → null). Marked noexcept — see the next box.
Copy deleted: copying would make two guards own one handle → double fclose.
Move defined: moving transfers ownership — the source's f is set to nullptr so its destructor closes nothing. This is the move completion of the Rule of Five: once you delete copy but own a resource, you must supply move (or the type becomes immovable, which is often too restrictive). Now FileGuard g = openLog(); can return a guard by value cheaply. Usage void read(){ FileGuard g("data.txt"); parse(g.get()); } closes the file even if parse throws.

Worked example Exercise 4.2 — scope-guarded counter

A shared int active must be incremented while a task runs and decremented when it finishes, even on exception. Write a Tracker RAII type, then predict the value of active after this loop:

int active = 0;
for (int i = 0; i < 3; ++i) {
    Tracker t(active);
    // ... work (may throw, caught outside) ...
}
// value of active here = ?

Recall Solution 4.2

struct Tracker {
    int& c;                                                  // reference to the shared counter
    explicit Tracker(int& counter): c(counter) { ++c; }      // grab
    ~Tracker() noexcept { --c; }                             // drop — cannot throw
};

Each loop iteration: ++active on construction (→ 1), then --active at the closing } (→ 0). Net change per iteration is 0. After the loop, active == 0. Because the decrement lives in the destructor, it fires even if the work throws — the counter can never get stuck too high. This is the same idea as lock_guard: acquire in the constructor, release in the destructor, and scope exit does the release on every path.

Level 5 — Mastery

Trace a full program with exceptions, order, and polymorphism together.

Worked example Exercise 5.1 — the grand trace

struct Loud {
    std::string id;
    Loud(std::string s): id(s) { std::cout << "+" << id << " "; }
    ~Loud() { std::cout << "-" << id << " "; }
};
void inner() {
    Loud x("x");
    throw std::runtime_error("boom");   // <-- exception here
    Loud y("y");                        // never reached
}
void outer() {
    Loud a("a");
    try { inner(); }
    catch (...) { std::cout << "[caught] "; }
    Loud b("b");
}

Write the exact output of outer().

Recall Solution 5.1

+a +x -x [caught] +b -b -a Step by step:

+a — a built in outer.
inner() called → +x.
throw fires. y was never constructed, so it is not destroyed. Stack unwinding destroys fully-built locals of inner in LIFO order → only x → -x.
Control lands in catch → [caught].
Execution continues past the try → +b.
outer ends: destroy b then a (LIFO) → -b -a. Key point: an object that was never fully constructed is never destroyed; only completed locals participate in unwinding. This is the guarantee that makes RAII exception-safe — provided none of those destructors throws while unwinding is already underway.

Worked example Exercise 5.2 — polymorphic ownership with a member

struct Log { ~Log(){ std::cout << "~Log "; } };
struct Shape        { virtual ~Shape(){ std::cout << "~Shape "; } };
struct Circle : Shape {
    Log lg;
    ~Circle(){ std::cout << "~Circle "; }
};
Shape* s = new Circle();
delete s;

Output? Then answer: what would break if ~Shape were not virtual?

Recall Solution 5.2

Output: ~Circle ~Log ~Shape ~Shape is virtual, so delete s (a Shape*) dispatches to the most-derived destructor. Order within one object: derived body ~Circle, then members in reverse declaration order (~Log), then base ~Shape. If ~Shape were non-virtual: delete s would call only ~Shape, printing just ~Shape — ~Circle and ~Log would be skipped. Any resource owned by Circle or its members would leak, and the behaviour of deleting a derived object through a non-virtual base pointer is actually undefined. Rule: a base used polymorphically needs a virtual destructor.

Recall Self-check score card

All L1–L2 correct? You recognise and apply the rules. ::: Solid foundation — you can read RAII code. L3 bugs spotted? ::: You understand why the Rule of Three and virtual destructors exist. L4–L5 designed/traced correctly? ::: You can write exception-safe RAII, handle move semantics, keep destructors noexcept, and reason about unwinding — mastery.

Connections

Destructor — RAII principle (parent)
Constructor — initialization
Rule of Three / Five / Zero
Smart Pointers — unique_ptr & shared_ptr
Exception Safety & Stack Unwinding
Virtual Functions & Polymorphism
Move Semantics
std::lock_guard & scope guards