C++ Smart Pointers: unique_ptr, shared_ptr Explained

The Problem Smart Pointers Solve

On the previous page you allocated memory with new and freed it with delete. That works, but it puts the burden on you: every new needs a matching delete, on every code path, including the ones where an exception is thrown halfway through. Miss one and you leak memory; run delete twice and you corrupt the heap.

Smart pointers fix this by tying the lifetime of heap memory to a normal object on the stack. When that object goes out of scope, its destructor runs delete for you - guaranteed, even if an exception unwinds the stack. This idea is called RAII (Resource Acquisition Is Initialization), and smart pointers live in the <memory> header.

#include <iostream>
#include <memory>
using namespace std;

int main() {
    unique_ptr<int> p = make_unique<int>(42);

    cout << *p << "\n";   // dereference like a normal pointer: 42

    // No delete needed. When p goes out of scope here,
    // the int is freed automatically.
    return 0;
}

You use *p and p->member exactly as you would a raw pointer. The difference is you never call delete - the smart pointer does it.

unique_ptr: One Owner, No Sharing

unique_ptr is the smart pointer you should reach for by default. It represents exclusive ownership: exactly one unique_ptr owns the object at a time, and when that pointer dies, the object dies with it. It has zero runtime overhead compared to a raw pointer.

Create one with make_unique (C++14). It takes the constructor arguments and hands you a ready-to-use pointer:

#include <iostream>
#include <memory>
#include <string>
using namespace std;

struct User {
    string name;
    int age;
    User(string n, int a) : name(n), age(a) {}
};

int main() {
    auto user = make_unique<User>("Ada", 36);

    cout << user->name << " is " << user->age << "\n";  // Ada is 36
    return 0;
}

Because there can only be one owner, a unique_ptr cannot be copied. Trying to copy it is a compile error - and that error is the language protecting you from two owners both trying to delete the same object:

auto a = make_unique<int>(10);
auto b = a;   // error: call to deleted copy constructor of unique_ptr

To hand ownership to someone else, you move it with std::move. After the move, the original pointer is empty (it holds nullptr):

#include <iostream>
#include <memory>
#include <utility>
using namespace std;

int main() {
    auto a = make_unique<int>(10);
    auto b = move(a);   // ownership transfers from a to b

    if (!a) cout << "a is now empty\n";
    cout << "b owns " << *b << "\n";   // b owns 10
    return 0;
}

This is the model you want most of the time: there is always exactly one clear owner, and the compiler enforces it.

shared_ptr: Shared Ownership by Reference Count

Sometimes several parts of your program genuinely need to share the same object, and none of them knows which will finish last. That's what shared_ptr is for. It keeps a reference count: each copy bumps the count up, each destruction bumps it down, and the object is freed only when the count hits zero.

Create them with make_shared:

#include <iostream>
#include <memory>
using namespace std;

int main() {
    auto a = make_shared<int>(99);
    cout << "count: " << a.use_count() << "\n";  // 1

    {
        auto b = a;   // copy is allowed - both share the int
        cout << "count: " << a.use_count() << "\n";  // 2
    }   // b dies here, count drops back to 1

    cout << "count: " << a.use_count() << "\n";  // 1
    return 0;
}

Unlike unique_ptr, copying a shared_ptr is fine - that's the whole point. The trade-off is cost: the reference count is stored on the heap and updated atomically (thread-safe), so shared_ptr is heavier than unique_ptr. Reach for it only when ownership is truly shared, not just to avoid thinking about who owns what.

make_shared is also more efficient than shared_ptr<T>(new T(...)): it allocates the object and the control block in a single allocation instead of two.

weak_ptr and Breaking Reference Cycles

shared_ptr has one classic trap: if two objects hold shared_ptrs to each other, their reference counts never reach zero, so neither is ever freed - a memory leak even though you used smart pointers.

struct Node {
    shared_ptr<Node> next;   // if two nodes point at each other,
};                           // they keep each other alive forever

The fix is weak_ptr: a non-owning observer of a shared_ptr. It does not raise the reference count, so it never keeps an object alive. To use the object, you call .lock(), which gives you a shared_ptr if the object still exists, or an empty one if it's already gone.

#include <iostream>
#include <memory>
using namespace std;

int main() {
    auto strong = make_shared<int>(7);
    weak_ptr<int> observer = strong;   // does not bump the count

    cout << "count: " << strong.use_count() << "\n";  // still 1

    if (auto locked = observer.lock()) {   // safely promote to shared_ptr
        cout << "still alive: " << *locked << "\n";
    }

    strong.reset();   // object is freed now

    if (observer.expired()) cout << "object is gone\n";
    return 0;
}

Use weak_ptr for "back pointers" and caches - anywhere you want to reference an object without claiming ownership of it.

Common Mistakes and Gotchas

Smart pointers remove most memory bugs, but a few traps remain:

Don't mix smart and raw ownership of the same memory. Never build two smart pointers from the same raw pointer - each will try to delete it:

int* raw = new int(5);
unique_ptr<int> a(raw);
unique_ptr<int> b(raw);   // disaster: both will delete the same int (double free)

This is exactly why you prefer make_unique/make_shared - there's no loose raw pointer to misuse.

A unique_ptr is move-only, so pass it by value to transfer ownership. If a function should use but not own the object, take a plain reference or a raw T* instead - a raw pointer that merely observes is perfectly fine:

void consume(unique_ptr<int> p);   // takes ownership (move into it)
void observe(int* p);              // just looks, owns nothing

Don't reach for shared_ptr by default. It is tempting because it copies freely, but the atomic reference counting costs real performance, and shared ownership makes lifetimes harder to reason about. Default to unique_ptr; upgrade to shared_ptr only when you actually need multiple owners.

unique_ptr for arrays needs the array form. make_unique<int[]>(n) gives you a unique_ptr<int[]> that calls delete[] correctly. In practice, prefer std::vector for dynamic arrays - it manages the memory for you and gives you size tracking on top.

Next: Strings

You now have memory management under control: smart pointers hand you heap allocation without the leaks. One of the most common things you'll allocate and pass around is text - and C++ gives you a much safer tool than raw char* buffers. The next page covers std::string: how it grows on its own, the operations you'll use every day, and why it frees you from manual memory work entirely.