Challenge 3: Forgetful vs. Deliberate-Misuse Bugs, With a Concrete Raw-Pointer Scenario — Possible Solution
====================================================================

The "FORGETFUL" class of bug, per the chapter, is a memory-management
mistake that happens simply because a programmer failed to remember to
do something -- the canonical example being c2-2's own forgotten
free() call, or cpp1-5's own Challenge 2 raw new with no matching
delete anywhere. Smart pointers eliminate this class structurally: a
unique_ptr's destructor calls delete AUTOMATICALLY, every single time,
with no possibility of a programmer simply forgetting to write the
corresponding cleanup call, since there's no separate cleanup call to
write at all.

The "DELIBERATE-MISUSE" class is different in kind: it's not about
forgetting to call a cleanup function -- it's about a program
containing MULTIPLE ways to reach the same object, where one of those
paths outlives the object's actual lifetime, and the programmer uses
that surviving path anyway (whether by oversight or genuine design
error). Smart pointers don't prevent a programmer from creating such an
extra path in the first place.

Concrete scenario:

    #include <memory>

    int* dangerous_raw_pointer;

    void setup() {
        std::unique_ptr<int> owner = std::make_unique<int>(42);
        dangerous_raw_pointer = owner.get();  // a raw pointer to the SAME object
    }  // owner goes out of scope HERE -- the int is deleted

    int main() {
        setup();
        int value = *dangerous_raw_pointer;  // use-after-free -- undefined behavior
        return 0;
    }

Here, owner.get() extracts a plain raw pointer to the same int the
unique_ptr owns, and stores it in a variable (dangerous_raw_pointer)
that outlives owner's own scope. When setup() returns, owner is
destroyed and deletes the int -- but dangerous_raw_pointer still holds
the now-invalid address, and dereferencing it in main is a genuine
use-after-free, exactly the kind of bug smart pointers are described as
NOT preventing. The unique_ptr itself behaved perfectly -- it deleted
its object exactly once, correctly, when it should have -- the bug
came entirely from a SEPARATE, deliberately-created raw pointer that
the smart pointer's own guarantees never extended to.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes the two bug classes by their actual root cause
(omitted cleanup code vs. an extra, unmanaged access path to the same
object) rather than treating them as a single vague "memory bug"
category, and constructs a genuinely working scenario where the
unique_ptr functions exactly as designed while a separate raw pointer
still produces a real use-after-free.