{"title":"std::weak_ptr","description":null,"content":"A `std::weak_ptr` is a non-owning handle that watches an object managed by `std::shared_ptr` without keeping it alive. It lets one part of your program hold a reference to a shared object while leaving the decision of when to destroy that object entirely to the owners. This chapter covers what `weak_ptr` is, how it interacts with the control block, the two operations you'll actually use (`lock` and `expired`), the common use cases, and how `enable_shared_from_this` lets a class safely hand out a `shared_ptr` to itself.\n\n---\n\n# What `weak_ptr` Is\n\nRecall from the previous chapter that every `std::shared_ptr` carries two things: a raw pointer to the managed object, and a pointer to a small heap-allocated **control block** that stores reference counts. The control block tracks two separate counts. The **strong count** is the number of `shared_ptr` instances that own the object. When the strong count drops to zero, the object is destroyed. The **weak count** is the number of `weak_ptr` instances plus one (for as long as there are any `shared_ptr` instances).\n\nA `weak_ptr` holds a pointer to the same control block, but **only** increments the weak count. It does not contribute to the strong count, so it can never extend the object's lifetime by itself.\n\n\n```cpp\n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n Product(std::string n, double p) : name(std::move(n)), price(p) {\n std::cout << \"Product \" << name << \" constructed\" << std::endl;\n }\n ~Product() {\n std::cout << \"Product \" << name << \" destroyed\" << std::endl;\n }\n};\n\nint main() {\n std::shared_ptr owner = std::make_shared(\"Headphones\", 79.99);\n std::weak_ptr observer = owner;\n\n std::cout << \"Strong count: \" << owner.use_count() << std::endl;\n\n owner.reset(); // last strong owner gone, object destroyed\n std::cout << \"After reset, observer is \"\n << (observer.expired() ? \"expired\" : \"alive\") << std::endl;\n return 0;\n}\n```\n\n\nThe `weak_ptr` named `observer` watched the same `Product` as `owner`. When `owner.reset()` ran, the strong count dropped from 1 to 0, the destructor fired, and the product was gone. The `weak_ptr` survived the destruction but now reports `expired() == true`. That's the entire idea: hold a handle that doesn't keep the object alive, and find out later whether it's still around.\n\n---\n\n# Construction Rules\n\nA `weak_ptr` is always constructed from something that already shares ownership. The two normal sources are a `shared_ptr` and another `weak_ptr`.\n\n\n```cpp\n#include \n\nint main() {\n auto strong = std::make_shared(42);\n\n std::weak_ptr w1 = strong; // from a shared_ptr\n std::weak_ptr w2 = w1; // from another weak_ptr\n std::weak_ptr empty; // default-constructed, expired immediately\n\n return 0;\n}\n```\n\n\nA default-constructed `weak_ptr` doesn't refer to any control block. Calling `expired()` on it returns `true`, and `lock()` returns an empty `shared_ptr`. That's safe but useless until you assign something into it.\n\nWhat you cannot do is dereference a `weak_ptr` directly. There is no `operator*`, no `operator->`, and no implicit conversion back to a raw pointer. The language enforces this because the moment you wanted to dereference, the object might already have been destroyed by another thread or another scope. The only safe way to access the object is to go through `lock()`, which first promotes the weak reference to a strong one.\n\n---\n\n# `lock()` and `expired()`\n\nThese two operations are the only way you'll interact with the underlying object through a `weak_ptr`.\n\n`lock()` atomically checks whether the strong count is still greater than zero. If it is, `lock` produces a new `std::shared_ptr` that participates in ownership for as long as you hold it, which guarantees the object stays alive while you use it. If the strong count is already zero (the object is gone), `lock` returns an empty `shared_ptr`.\n\n`expired()` returns `true` if the strong count is zero. It's a cheap query and does not produce a `shared_ptr`. It exists mostly for diagnostics and quick branching when you're not about to access the object.\n\n\n```cpp\n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nvoid printIfAlive(const std::weak_ptr& watcher) {\n if (auto p = watcher.lock()) {\n std::cout << p->name << \" costs $\" << p->price << std::endl;\n } else {\n std::cout << \"Product no longer in catalog\" << std::endl;\n }\n}\n\nint main() {\n auto headphones = std::make_shared(Product{\"Headphones\", 79.99});\n std::weak_ptr watcher = headphones;\n\n printIfAlive(watcher);\n\n headphones.reset(); // catalog removes the product\n\n printIfAlive(watcher);\n return 0;\n}\n```\n\n\n`lock()` is the safe pattern. It returns a `shared_ptr` you can check with an `if`, and as long as that `shared_ptr` is in scope, the object cannot be destroyed even if every other strong owner releases it. That's the only way to use the object without a window where it might vanish underneath you.\n\nThe temptation is to write `if (!watcher.expired()) { auto p = watcher.lock(); ... }`. Don't. Between the `expired()` check and the `lock()` call, another thread (or even a scoped destructor on this thread) could release the last strong owner. The check would pass and the lock would still return an empty pointer. **Always use the result of `lock()` directly.**\n\n\n> **INFO**\n>\n> **Cost note:** `lock()` is more expensive than a raw pointer dereference because it touches the control block's reference counts atomically. It's still fast, but inside a tight inner loop where you're certain the object is alive, hold a `shared_ptr` once at the top instead of calling `lock()` on every iteration.\n\n\n---\n\n# Where `weak_ptr` Actually Helps\n\nThere are three places `weak_ptr` earns its keep in everyday code.\n\n### Observers that don't extend lifetime\n\nA wishlist is a list of products a customer is interested in. The catalog owns the products. If the wishlist held `shared_ptr` values, every wishlisted product would be kept alive by the wishlist itself, even after the catalog removed it. That defeats the catalog's authority over the product's lifetime. With `weak_ptr`, the wishlist watches the products without owning them.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nclass Catalog {\npublic:\n std::shared_ptr add(std::string name, double price) {\n auto p = std::make_shared(Product{std::move(name), price});\n products_.push_back(p);\n return p;\n }\n void remove(const std::string& name) {\n std::erase_if(products_, [&](const std::shared_ptr& p) {\n return p->name == name;\n });\n }\nprivate:\n std::vector> products_;\n};\n\nclass Wishlist {\npublic:\n void add(std::shared_ptr p) { items_.push_back(p); }\n\n void print() const {\n for (const auto& watcher : items_) {\n if (auto p = watcher.lock()) {\n std::cout << \" - \" << p->name << \" $\" << p->price << std::endl;\n } else {\n std::cout << \" - (item no longer available)\" << std::endl;\n }\n }\n }\nprivate:\n std::vector> items_;\n};\n\nint main() {\n Catalog catalog;\n Wishlist wishlist;\n\n wishlist.add(catalog.add(\"Headphones\", 79.99));\n wishlist.add(catalog.add(\"Mouse Pad\", 14.99));\n\n std::cout << \"Before removal:\" << std::endl;\n wishlist.print();\n\n catalog.remove(\"Headphones\");\n\n std::cout << \"After removal:\" << std::endl;\n wishlist.print();\n return 0;\n}\n```\n\n\nThe catalog deleted \"Headphones\" and the wishlist saw it the next time it tried to display. The wishlist didn't have to subscribe to a removal event or be told ahead of time. It just asked, \"is this still alive?\" at the moment it needed the answer.\n\n### Caches that don't pin their entries\n\nA cache that uses `shared_ptr` to its values keeps every cached entry alive forever, defeating the point. A cache built on `weak_ptr` returns the cached value if it's still alive somewhere else in the program, and otherwise rebuilds it. The cache acts as a fast lookup without holding entries hostage.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nclass ProductCache {\npublic:\n std::shared_ptr get(const std::string& name) {\n auto it = entries_.find(name);\n if (it != entries_.end()) {\n if (auto cached = it->second.lock()) {\n std::cout << \"[cache hit] \" << name << std::endl;\n return cached;\n }\n }\n std::cout << \"[cache miss] \" << name << std::endl;\n auto fresh = std::make_shared(Product{name, 19.99});\n entries_[name] = fresh;\n return fresh;\n }\nprivate:\n std::unordered_map> entries_;\n};\n\nint main() {\n ProductCache cache;\n {\n auto a = cache.get(\"Headphones\");\n auto b = cache.get(\"Headphones\"); // same object, still alive\n } // both go out of scope; the cached object is destroyed\n\n auto c = cache.get(\"Headphones\"); // miss again, builds fresh\n return 0;\n}\n```\n\n\nThe cache held a `weak_ptr` to the product. While `a` and `b` were alive, the strong count was positive and `lock()` succeeded. Once they fell out of scope, the entry expired and the next request had to rebuild.\n\n### Parent pointers in tree and graph structures\n\nTrees, graphs, and any data structure with bidirectional links run into the same trap: parent owns child via `shared_ptr`, child also points back to parent via `shared_ptr`, and now neither can ever drop its count to zero. The strong counts hold each other up, the destructors never fire, and you leak the entire structure.\n\nThe fix is straightforward: pick the direction of ownership, use `shared_ptr` going one way, and use `weak_ptr` going the other. In a tree, parents own children via `shared_ptr` and children watch their parent via `weak_ptr`. Cycles can't form because the weak count doesn't keep anything alive.\n\nThis chapter only sketches the problem so you know `weak_ptr` is the right tool. The next-chapter-but-one (**Smart Pointer Pitfalls**) walks through circular references in detail, with the exact reference-count diagrams that show why two `shared_ptr` instances pointing at each other leak and how the `weak_ptr` fix breaks the cycle.\n\n---\n\n# The Control Block Outlives the Object\n\nThis is the part of `weak_ptr` that surprises most people. When the strong count drops to zero, the **object** is destroyed (its destructor runs and its memory is freed if appropriate). But the **control block** sticks around as long as the weak count is non-zero. It has to: every existing `weak_ptr` still holds a pointer to it and still needs to call `expired()` or `lock()` safely.\n\n\n```mermaid\nflowchart LR\n subgraph S1[State 1: object alive]\n SP1[shared_ptr
strong: 1]:::cyan\n WP1[weak_ptr
weak: 1]:::orange\n CB1[Control Block
strong=1, weak=2]:::teal\n OBJ1[Product object
alive]:::green\n SP1 --> CB1\n WP1 --> CB1\n CB1 --> OBJ1\n end\n\n subgraph S2[State 2: shared_ptr reset]\n WP2[weak_ptr
weak: 1]:::orange\n CB2[Control Block
strong=0, weak=1]:::teal\n OBJ2[Product object
DESTROYED]:::red\n WP2 --> CB2\n CB2 -.->|gone| OBJ2\n end\n\n S1 -->|owner.reset| S2\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nIn state 1, a `shared_ptr` and a `weak_ptr` both refer to the same control block, which in turn manages a live `Product`. The strong count is 1 and the weak count is 2 (one for the `weak_ptr`, plus one accounting for the fact that strong owners exist). When the `shared_ptr` is reset, the strong count hits zero and the `Product` is destroyed. The control block is still allocated, because the `weak_ptr` is still there and still needs to be queryable. Only when the last `weak_ptr` also goes away does the control block itself get freed.\n\nThere is a practical consequence to this. If you use `std::make_shared` (covered in the next lesson), the control block and the object are allocated together as a single heap block. That block can only be freed when **both** counts are zero. So if you hold a `weak_ptr` long after every `shared_ptr` is gone, you're keeping that combined block alive even though the object itself is dead. For tiny objects this doesn't matter; for very large objects, holding many long-lived `weak_ptr` instances can be a real memory concern.\n\n---\n\n# `enable_shared_from_this`\n\nA class sometimes needs to hand out a `shared_ptr` to itself. The classic situation is a member function that wants to register `this` somewhere as an observer, schedule a callback that calls back into `this`, or hand `this` to another object that expects shared ownership.\n\nThe naive attempt is to wrap `this` in a fresh `shared_ptr` and return it.\n\n**What's wrong with this code?**\n\n\n```cpp\n#include \n#include \n\nstruct Bad {\n std::shared_ptr share() {\n return std::shared_ptr(this); // BUG\n }\n};\n\nint main() {\n auto a = std::make_shared();\n auto b = a->share(); // a and b now each think they own *this\n return 0;\n}\n```\n\n\nThe `shared_ptr` returned by `share()` knows nothing about the existing `shared_ptr` named `a`. It creates a brand new control block with its own strong count of 1. Now two separate control blocks each believe they own the same `Bad` object. When `b` goes out of scope its control block deletes the `Bad`. When `a` goes out of scope its control block tries to delete the same `Bad` a second time. This is undefined behavior and typically crashes with a double-free.\n\nThe fix is `std::enable_shared_from_this`. You inherit from it, and inside any member function you call `shared_from_this()` to get a `shared_ptr` that **shares the existing control block** rather than inventing a new one.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nclass Product : public std::enable_shared_from_this {\npublic:\n Product(std::string name, double price)\n : name_(std::move(name)), price_(price) {}\n\n void registerWith(std::vector>& watchers) {\n watchers.push_back(shared_from_this());\n }\n\n const std::string& name() const { return name_; }\n double price() const { return price_; }\n\nprivate:\n std::string name_;\n double price_;\n};\n\nint main() {\n std::vector> wishlist;\n auto headphones = std::make_shared(\"Headphones\", 79.99);\n headphones->registerWith(wishlist);\n\n for (const auto& w : wishlist) {\n if (auto p = w.lock()) {\n std::cout << p->name() << \" $\" << p->price() << std::endl;\n }\n }\n return 0;\n}\n```\n\n\nTwo rules apply when you use `enable_shared_from_this`:\n\n1. **The object must already be owned by a `shared_ptr` before you call `shared_from_this()`.** The base class stores a `weak_ptr` to `this` internally, and that weak pointer is wired up the first time a `shared_ptr` takes ownership of the object. Calling `shared_from_this()` before any `shared_ptr` exists throws `std::bad_weak_ptr` (since C++17). Earlier standards left it as undefined behavior.\n2. **Never call `shared_from_this()` from inside a constructor or a destructor.** During the constructor the `shared_ptr` hasn't finished wiring itself to the object yet; during the destructor the strong count is already zero, so there's nothing left to share.\n\nIf you're designing a class whose objects will always live behind a `shared_ptr`, a common pattern is to make the constructor private and expose a static `create()` function that returns `std::make_shared(...)`. That makes the precondition impossible to violate.\n\n\n> **INFO**\n>\n> **Cost note:** Inheriting from `enable_shared_from_this` adds the size of one `weak_ptr` to every instance of your class. For most classes this is negligible. For very small value types that you instantiate by the millions, it's worth being aware of.\n\n\n---\n\n# Summary\n\n- `std::weak_ptr` is a non-owning handle that watches an object managed by `std::shared_ptr`. It contributes to the control block's weak count but never to the strong count, so it cannot keep the object alive.\n- A `weak_ptr` cannot be dereferenced directly. Use `lock()` to atomically promote it to a `std::shared_ptr`, and check whether the returned pointer is empty before using it.\n- `expired()` is a cheap query, but acting on its result without `lock()` introduces a time-of-check to time-of-use race. Prefer `if (auto p = w.lock())` as the canonical pattern.\n- Use `weak_ptr` for observers that shouldn't extend lifetime (wishlists watching catalog items), for caches that shouldn't pin their entries, and for back-pointers in trees and graphs that would otherwise form cycles.\n- When the last `shared_ptr` is destroyed, the managed object is destroyed immediately, but the control block lives on until the weak count also reaches zero. Every existing `weak_ptr` continues to work safely throughout.\n- A class that needs to hand out a `shared_ptr` to itself must inherit from `std::enable_shared_from_this` and call `shared_from_this()`. Wrapping `this` in a fresh `shared_ptr` creates a second control block and leads to a double-free.\n- `shared_from_this()` requires the object to already be owned by a `shared_ptr` and is not callable from a constructor or destructor. Since C++17, calling it without an owning `shared_ptr` throws `std::bad_weak_ptr`.\n\nThe next chapter, **std::make_unique & std::make_shared**, looks at the factory functions that build smart pointers in a single allocation, why they're preferred over calling `new` directly inside a `shared_ptr` constructor, and the subtle interaction between `make_shared`, `weak_ptr`, and how long that combined heap block actually lives.","pageType":"cpp"}

std::weak_ptr

Get Premium