Memory & Smart Pointers

Memory management is C++'s most famous footgun. Modern C++ defangs it with RAII, standard containers, and smart pointers. Master them and you'll virtually never new/delete again.

The Manual Way (and Why It's Bad)

int*    n   = new int(42);          // allocate
int*    arr = new int[100];          // allocate array
delete  n;                           // free single
delete[] arr;                        // free array — NOTE the []

Problems: 1. Leak if you forget to delete (or an exception skips it) 2. Double-free if you delete twice 3. Use-after-free if you keep using a deleted pointer 4. Wrong delete form (delete vs delete[]) → undefined behaviour

Avoid new/delete in modern code. Use make_unique/make_shared and standard containers.

RAII Recap

> *Resource Acquisition Is Initialisation* — own resources in objects, release them in destructors.

std::vector, std::string, std::ifstream, std::unique_ptr — all RAII wrappers around raw resources.

std::unique_ptr — The Default

Sole, exclusive ownership. Cannot be copied (would mean two owners) — but can be moved.

#include <memory>
auto p = make_unique<Widget>(arg1, arg2);    // construct on heap
p->doStuff();
(*p).field = 42;
// auto q = p;          // ❌ compile error — can't copy
auto q = std::move(p);   // ✅ transfer ownership; p becomes nullptr

Returning From Factory Functions

unique_ptr<Shape> makeShape(string kind) {
    if (kind == "circle")    return make_unique<Circle>(5);
    if (kind == "rectangle") return make_unique<Rectangle>(3, 4);
    return nullptr;
}

Returning by value moves the unique_ptr out — no copy, no leak.

Owning Polymorphic Objects

vector<unique_ptr<Animal>> zoo;
zoo.push_back(make_unique<Dog>());
zoo.push_back(make_unique<Cat>());
for (const auto& a : zoo) a->speak();
// All animals freed when 'zoo' is destroyed

Owning Arrays

auto buf = make_unique<int[]>(100);    // 100 ints, zero-initialised
buf[0] = 42;
// (Usually prefer std::vector — more features.)

std::shared_ptr — Shared Ownership

Multiple owners, reference-counted. The object dies when the last shared_ptr to it goes away.

auto a = make_shared<Image>("photo.png");
auto b = a;                  // ref count = 2
{
    auto c = a;              // ref count = 3
}                            // c destroyed → ref count = 2
// when a and b also die → ref count = 0 → Image deleted

When To Use shared_ptr

• A graph of objects with multiple owners
• Async code where you can't predict which task ends last
• Caches and multi-thread shared state

When NOT To Use shared_ptr

• For convenience to avoid figuring out ownership — that's a code smell
• Single-owner cases (use unique_ptr)
• Hot loops (atomic ref counting has cost)

Cyclic References & weak_ptr

Two shared_ptrs that point to each other never reach refcount 0 — memory leak.

struct Node {
    shared_ptr<Node> next;
};
auto a = make_shared<Node>();
auto b = make_shared<Node>();
a->next = b;
b->next = a;          // ❌ cycle — never freed

Break the cycle with weak_ptr (non-owning observer):

struct Node {
    shared_ptr<Node> next;
    weak_ptr<Node>   prev;       // doesn't keep prev alive
};

To use a weak_ptr, lock it back to a shared_ptr (returns null if already deleted):

if (auto p = wptr.lock()) {
    p->doSomething();
}

Raw Pointers — Still Have a Use

Raw T* is fine for non-owning parameters:

void inspect(const Widget* w);     // optional — caller still owns
void log(const Widget& w);         // required — caller still owns
unique_ptr<Widget> w = ...;
inspect(w.get());                   // pass raw pointer

Custom Deleters (advanced)

unique_ptr accepts a custom deleter — handy for C resources:

unique_ptr<FILE, decltype(&fclose)> file(fopen("a.txt", "r"), &fclose);
// auto-closes when 'file' goes out of scope

Cheat-Sheet

You now write C++ that doesn't leak, doesn't double-free, and doesn't crash on exceptions — without ever calling delete. That's the modern C++ promise.

Next: templates — generic code that works for any type.