Challenge 2: Why RAII Doesn't Protect Against a Forgotten delete — Possible Solution
====================================================================

#include <iostream>

class Circle {
public:
    double radius;
    Circle(double r) { radius = r; }
    ~Circle() { std::cout << "Circle destroyed" << std::endl; }
};

int main() {
    Circle *c = new Circle(5.0);
    // deliberately never calling delete c;
    return 0;
}

Running this produces NO "Circle destroyed" output at all -- the
object is never destroyed, and the memory `new` allocated for it is
never freed.

This is a genuine memory LEAK, per c2-2's own terminology -- allocated
memory that's never freed, with no remaining pointer to it once the
program exits (or once c itself goes out of scope without a delete
call, whichever comes first).

Why RAII doesn't protect against this specific mistake: RAII's actual
guarantee, per the chapter, is that a destructor runs automatically
when an OBJECT'S OWN LIFETIME ends via normal scope exit. But
`c` here is a raw POINTER to a heap-allocated Circle, not the Circle
object's own automatic-storage lifetime being tracked -- the pointer
variable `c` itself does go out of scope at the end of main (its own
stack storage is reclaimed), but that only destroys the POINTER, not
the object it points to. The Circle object living on the heap has no
lifetime tied to any scope at all; it persists until something
explicitly calls `delete` on it, and nothing here ever does. RAII
protects objects whose OWN construction/destruction is tied to a
scope -- it says nothing about raw pointers to heap objects, which is
exactly the gap Course 2's smart pointers (unique_ptr/shared_ptr) exist
to close, by wrapping the raw pointer in an object that itself DOES
have RAII-managed, scope-tied ownership.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the bug as a memory leak using c2-2's own
vocabulary, and precisely distinguishes between the pointer variable's
own (irrelevant) scope-tied lifetime and the heap object's own
lifetime, which nothing here ties to any scope at all -- explaining
exactly why raw new/delete alone doesn't automatically deliver RAII's
guarantee without a wrapper object managing it.