Beyond new and delete: to Weak Pointer

In the previous article, we left one case untouched: the transition from raw pointers to weak_ptr. That's exactly what we'll dive into today.

Use shared_ptr when multiple parts of your system need to keep an object alive, and you can't predict which part will outlive the others. But shared_ptr has a fatal flaw: cyclic references.

When two shared_ptrs point to each other, neither can die. They hold each other hostage forever. The result? A memory leak that never gets cleaned up.

Let me break it down step by step.

The Core Problem: What happens when objects point to each other?

Normal case (no cycle)

class Person {
    std::shared_ptr<Person> mother;  // Owning reference
};

auto alice = std::make_shared<Person>();
auto bob = std::make_shared<Person>();

// alice's reference count = 1
// bob's reference count = 1
// When they go out of scope, both are destroyed ✅

The cyclic problem

class Person {
    std::shared_ptr<Person> mother;
    std::shared_ptr<Person> father;
};

auto alice = std::make_shared<Person>();  // alice ref count = 1
auto bob = std::make_shared<Person>();    // bob ref count = 1

alice->father = bob;   // bob's ref count becomes 2
bob->mother = alice;   // alice's ref count becomes 2

Now what happens when alice and bob go out of scope?

• alice (the variable) is destroyed → alice's ref count drops from 2 → 1
• bob (the variable) is destroyed → bob's ref count drops from 2 → 1
• Both objects still have ref count = 1! They point to each other, so neither can be destroyed.
• MEMORY LEAK 💥

The Solution: weak_ptr

weak_ptr is like a "peek" at the object — it doesn't increase the reference count.

class Person {
    std::shared_ptr<Person> mother;  // Owning (increases count)
    std::weak_ptr<Person> father;    // Observing (doesn't increase count)
};

auto alice = std::make_shared<Person>();  // alice count = 1
auto bob = std::make_shared<Person>();    // bob count = 1

alice->father = bob;   // bob's count stays 1 (weak_ptr doesn't affect it)
bob->mother = alice;   // alice's count becomes 2

// When variables go out of scope:
// bob count: 1 → 0 (destroyed)
// alice count: 2 → 1 → 0 (destroyed when bob's weak_ptr expires)
// NO LEAK! ✅

Using weak_ptr: The .lock() method

You can't use a weak_ptr directly — you must first "lock" it to get a temporary shared_ptr. .lock() atomically checks existence and acquires a shared_ptr in one thread-safe operation — there is no other safe way to access a weak_ptr's target.

// BAD: Can't use weak_ptr directly
father->doSomething();  // Compiler error!

// GOOD: Lock it first
if (auto temp = father.lock()) {  // Try to get shared_ptr
    temp->doSomething();           // Use it safely
} else {
    // The object has been destroyed
    std::cout << "Father is gone\n";
}

Real-World Examples

1. Parent-child relationships

class Node {
    std::vector<std::shared_ptr<Node>> children;  // Owning
    std::weak_ptr<Node> parent;                   // Observing (back-pointer)
};

2. Event observers

class Button {
    std::vector<std::weak_ptr<ClickObserver>> observers;  // Non-owning

    void onClick() {
        for (auto& weakObs : observers) {
            if (auto obs = weakObs.lock()) {
                obs->notify();
            }
        }
        // Clean up dead observers
        observers.erase(remove_if(...));
    }
};

3. Caches

class ImageCache {
    std::map<std::string, std::weak_ptr<Image>> cache;

    std::shared_ptr<Image> get(const std::string& path) {
        auto it = cache.find(path);
        if (it != cache.end()) {
            if (auto img = it->second.lock()) {
                return img;  // Still in use, return it
            }
        }
        // Not in cache or expired, load new image
        auto img = std::make_shared<Image>(path);
        cache[path] = img;  // Store as weak_ptr
        return img;
    }
};

The shared_ptr.get() -> weak_ptr

The comment about .get() means: If you ever write this:

// BAD pattern
std::shared_ptr<Widget> sp = std::make_shared<Widget>();
Widget* raw = sp.get();  // Storing raw pointer
// Later: use raw somewhere else — DANGEROUS!

That's usually a sign you should use weak_ptr instead:

// GOOD pattern
std::shared_ptr<Widget> sp = std::make_shared<Widget>();
std::weak_ptr<Widget> wp = sp;  // Non-owning reference
// Later: wp.lock() to safely access

Key Takeaways

shared_ptr	weak_ptr
Owns the object	Observes the object
Increases ref count	Doesn't affect ref count
Keeps object alive	Object can die
Always valid (until destroyed)	May be expired
Direct access with ->	Must call .lock() first

When to use weak_ptr: Any time you need a reference to an object but don't want to be responsible for keeping it alive — especially parent back-pointers, observers, and caches.

Does this make the cyclic reference problem clearer?