{"title":"std::shared_ptr","description":null,"content":"`std::shared_ptr` is a smart pointer that lets multiple owners share a single heap object and frees it only when the last owner goes away. It works by keeping a reference count: every time you copy the pointer, the count goes up, and every time a `shared_ptr` is destroyed, the count goes down. When the count hits zero, the object is deleted. This chapter covers what `shared_ptr` is, how its control block works, what its member functions do, what it costs compared with `std::unique_ptr`, and the parts of its design that show up in interviews.\n\n---\n\n# When Shared Ownership Actually Makes Sense\n\nMost ownership in C++ is single-owner. One container, one function, one parent object owns the value, and that owner decides when it dies. `std::unique_ptr` models that case and is the right default.\n\nShared ownership is for the cases where you genuinely can't say in advance which referent will be the last one alive. Consider an online store. A `Product` object is referenced from a customer's cart and also from their wishlist. The customer could empty the cart first, or remove the wishlist entry first. Whichever happens last is the one that should free the product. Neither side wants to be the owner because neither side can promise to outlive the other.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nclass Product {\npublic:\n Product(std::string name, double price)\n : name_(std::move(name)), price_(price) {\n std::cout << \"Product \" << name_ << \" constructed\" << std::endl;\n }\n ~Product() {\n std::cout << \"Product \" << name_ << \" destroyed\" << std::endl;\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::shared_ptr headphones =\n std::make_shared(\"Wireless Headphones\", 79.99);\n\n std::vector> cart;\n std::vector> wishlist;\n\n cart.push_back(headphones);\n wishlist.push_back(headphones);\n\n std::cout << \"Use count: \" << headphones.use_count() << std::endl;\n\n cart.clear();\n std::cout << \"After cart clear, use count: \"\n << headphones.use_count() << std::endl;\n\n wishlist.clear();\n std::cout << \"After wishlist clear, use count: \"\n << headphones.use_count() << std::endl;\n\n return 0;\n}\n```\n\n\nThree `shared_ptr`s pointed at the same `Product`: one local variable, one in the cart, one in the wishlist. The count dropped as containers were emptied, and the destructor only ran when the local variable went out of scope at the end of `main`, where the count finally reached zero. No call to `delete` anywhere, and no risk of double-freeing the product when both containers happen to hold the last copy.\n\n`std::make_shared(args...)` (C++11) is the preferred way to build a `shared_ptr`. The short version is that it allocates the object and the bookkeeping in a single allocation. Use it unless you have a specific reason not to.\n\n---\n\n# The Control Block\n\nA `shared_ptr` is more than just a pointer. To make reference counting work, it carries a second pointer to a small heap-allocated structure called the **control block**. Every `shared_ptr` that owns the same object shares the same control block.\n\nThe control block holds:\n\n- **Strong count.** The number of `shared_ptr` instances currently owning the object. When this drops to zero, the object's destructor runs.\n- **Weak count.** The number of `std::weak_ptr` instances observing the object, plus one for \"the object is still alive.\" When the strong count hits zero the object is destroyed, but the control block itself only goes away when the weak count also reaches zero.\n- **Deleter.** A type-erased function or function object that knows how to destroy the managed object. Defaults to `delete ptr`, but you can supply your own.\n- **Allocator.** A type-erased allocator used to free the control block itself. Defaults to the standard allocator.\n\n\n```mermaid\nflowchart LR\n SP1[shared_ptr A
ptr + ctrl]:::cyan\n SP2[shared_ptr B
ptr + ctrl]:::cyan\n SP3[shared_ptr C
ptr + ctrl]:::cyan\n\n CB[Control Block
strong: 3
weak: 0
deleter
allocator]:::orange\n\n OBJ[Product object
on the heap]:::green\n\n SP1 -->|ptr| OBJ\n SP2 -->|ptr| OBJ\n SP3 -->|ptr| OBJ\n\n SP1 -->|ctrl| CB\n SP2 -->|ctrl| CB\n SP3 -->|ctrl| CB\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram shows three `shared_ptr` variables pointing at the same `Product` on the heap, all wired to the same control block. Each `shared_ptr` itself is two pointer-sized fields: one for the managed object, one for the control block. The control block is small but distinct from the object, and it lives on the heap independently.\n\nThe \"weak count is strong-count-plus-one when the object is alive\" detail matters for an edge case. As long as there are any `shared_ptr`s, the weak count is at least 1. When the last `shared_ptr` dies, the strong count hits zero, the object is destroyed, and the weak count is decremented from \"1 + any weak_ptrs\" to \"any weak_ptrs\". If no `weak_ptr`s exist, the control block is freed immediately too. If `weak_ptr`s do exist, the control block survives until they're all gone, which lets them safely detect that the object is dead.\n\n---\n\n# Constructing a shared_ptr\n\nThere are three common ways to construct a `shared_ptr`. They are not equivalent.\n\n### From a raw pointer\n\nYou can hand a `shared_ptr` a freshly-`new`-ed pointer and ask it to take over.\n\n\n```cpp\n#include \n#include \n#include \n\nclass Product {\npublic:\n Product(std::string name, double price)\n : name_(std::move(name)), price_(price) {}\n const std::string& name() const { return name_; }\n\nprivate:\n std::string name_;\n double price_;\n};\n\nint main() {\n // Works, but discouraged.\n std::shared_ptr p(new Product(\"USB Cable\", 9.99));\n std::cout << \"Owns: \" << p->name() << std::endl;\n return 0;\n}\n```\n\n\nThis compiles and runs, but it has a subtle cost. The `new Product(...)` allocates the product on the heap. Then the `shared_ptr` constructor allocates the control block separately. That's two heap allocations for a single shared object.\n\nThere's also a safety issue. If you write `foo(std::shared_ptr(new A), std::shared_ptr(new B))` and the `new B` throws after `new A` succeeds, the raw pointer to `A` leaks because no one has wrapped it yet. The construction from raw pointer can't apply RAII to the raw allocation it didn't make.\n\n### From `std::make_shared`\n\nThe preferred way:\n\n\n```cpp\n#include \n#include \n#include \n\nclass Product {\npublic:\n Product(std::string name, double price)\n : name_(std::move(name)), price_(price) {}\n const std::string& name() const { return name_; }\n\nprivate:\n std::string name_;\n double price_;\n};\n\nint main() {\n auto p = std::make_shared(\"USB Cable\", 9.99);\n std::cout << \"Owns: \" << p->name() << std::endl;\n return 0;\n}\n```\n\n\n`std::make_shared` allocates the object and the control block in **one** contiguous heap block. That's one allocation instead of two, the object data sits next to its control block for better cache behavior, and there's no leak window. The main trade-off is that the memory isn't released until the last `weak_ptr` also dies, which can matter when the object is large.\n\n### By copying or moving an existing `shared_ptr`\n\nCopying shares ownership. Moving transfers it.\n\n\n```cpp\n#include \n#include \n#include \n\nint main() {\n auto a = std::make_shared(\"Mouse Pad\");\n std::cout << \"a count: \" << a.use_count() << std::endl;\n\n auto b = a; // copy: both own the string\n std::cout << \"after copy, a count: \" << a.use_count()\n << \", b count: \" << b.use_count() << std::endl;\n\n auto c = std::move(a); // move: c takes over, a becomes empty\n std::cout << \"after move, a count: \" << a.use_count()\n << \", b count: \" << b.use_count()\n << \", c count: \" << c.use_count() << std::endl;\n\n return 0;\n}\n```\n\n\nThe copy bumps the strong count from 1 to 2. The move from `a` to `c` doesn't change the count at all: `a` hands off its ownership to `c` and becomes empty (its internal pointers are null), so the total number of owning `shared_ptr`s is still 2.\n\n\n> **INFO**\n>\n> **Cost:** Copying a `shared_ptr` performs an **atomic increment** on the strong count, and destroying one performs an **atomic decrement**. Moves don't touch the count at all. Prefer to move `shared_ptr`s when you don't need an extra owner, especially across thread boundaries, where the atomic operations are most expensive.\n\n\n---\n\n# Member Functions You'll Actually Use\n\nA `shared_ptr` exposes a small interface. Most code uses only a handful of these.\n\n\n| Member | What it does |\n|--------|--------------|\n| `get()` | Returns the underlying raw pointer. Does not transfer ownership. |\n| `operator*` | Dereferences and gives you `T&`. |\n| `operator->` | Member access on the pointed-to object. |\n| `operator bool()` | True if the `shared_ptr` is non-empty. |\n| `use_count()` | Returns the current strong count. Mostly useful for debugging. |\n| `unique()` | Returns `true` if the strong count is 1. Deprecated in C++17, removed in C++20. Use `use_count() == 1` instead. |\n| `reset()` | Drops ownership of the current object. Optional argument adopts a new one. |\n| `swap(other)` | Exchanges the managed object and control block with another `shared_ptr`. |\n\n\n\n```cpp\n#include \n#include \n#include \n\nclass Product {\npublic:\n Product(std::string name) : name_(std::move(name)) {}\n const std::string& name() const { return name_; }\n\nprivate:\n std::string name_;\n};\n\nint main() {\n auto p = std::make_shared(\"Wireless Headphones\");\n\n // operator-> and operator*\n std::cout << \"Name via ->: \" << p->name() << std::endl;\n std::cout << \"Name via *: \" << (*p).name() << std::endl;\n\n // operator bool() and use_count()\n if (p) {\n std::cout << \"Holds an object, count = \" << p.use_count() << std::endl;\n }\n\n auto q = p;\n std::cout << \"After copy, count = \" << p.use_count() << std::endl;\n\n // reset() with no argument: drop the current object\n q.reset();\n std::cout << \"After q.reset(), p count = \" << p.use_count()\n << \", q empty? \" << !q << std::endl;\n\n // reset() with a new object: drop the old, take the new\n p.reset(new Product(\"USB Cable\"));\n std::cout << \"p now holds: \" << p->name()\n << \", count = \" << p.use_count() << std::endl;\n\n return 0;\n}\n```\n\n\nA note on `get()`: the returned raw pointer is only valid as long as some `shared_ptr` still owns the object. Never call `delete` on the result of `get()` (that would double-free), and never wrap it in another independent `shared_ptr` (that would create a second control block and free the same object twice).\n\n\n```cpp\n// Don't do this.\nauto p = std::make_shared(\"USB Cable\");\nstd::shared_ptr bad(p.get()); // second control block; double free at end\n```\n\n\n---\n\n# Thread Safety, Precisely\n\nThis is the area that trips people up most often, so it's worth being exact.\n\nThe control block's strong and weak counts are atomic. Two threads can each hold their own `shared_ptr` to the same object and copy, destroy, or `reset` their own instances simultaneously without corrupting the count.\n\nThe **pointed-to object** is not made thread-safe by `shared_ptr`. If two threads call non-const methods on the same `Product` through `shared_ptr`s, you still need a mutex or some other synchronization. `shared_ptr` only protects its own bookkeeping.\n\nAnd the `shared_ptr` instance itself (the local variable holding the two pointers) is not internally synchronized. If two threads both modify the **same** `shared_ptr` variable (one calls `reset()` while the other copies it), that's a data race. C++20 added `std::atomic>` for cases where you genuinely need a shared `shared_ptr` variable mutated by multiple threads.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n};\n\nint main() {\n auto p = std::make_shared(Product{\"Wireless Headphones\"});\n\n std::vector threads;\n for (int i = 0; i < 4; ++i) {\n // Each thread captures its OWN copy of the shared_ptr.\n threads.emplace_back([p]() {\n // Bumping and dropping our own copy is safe across threads.\n auto local = p;\n std::cout << local->name << std::endl;\n });\n }\n for (auto& t : threads) t.join();\n return 0;\n}\n```\n\n\nThe lambda captures `p` by value, so each thread gets its own `shared_ptr` instance. The strong count goes up to 5 at peak (one outside, four inside the threads) and decrements as each thread finishes. The atomic operations on the count are what make that safe.\n\n---\n\n# Custom Deleters\n\nBy default, a `shared_ptr` calls `delete` on the managed pointer. You can pass a different deleter to handle resources that need different cleanup. The deleter is stored in the control block, so it doesn't affect the static type of the `shared_ptr`.\n\n\n```cpp\n#include \n#include \n#include \n\nint main() {\n // FILE* needs fclose, not delete. A custom deleter handles it.\n std::shared_ptr log(\n std::fopen(\"/tmp/cart.log\", \"w\"),\n [](FILE* f) {\n if (f) {\n std::cout << \"Closing log file\" << std::endl;\n std::fclose(f);\n }\n }\n );\n\n if (log) {\n std::fputs(\"Order placed\\n\", log.get());\n }\n return 0;\n}\n```\n\n\nThe lambda runs when the last `shared_ptr` to the `FILE*` is destroyed. Notice the type is still `std::shared_ptr`; the deleter doesn't appear in the template arguments. This is different from `std::unique_ptr`, where the deleter is part of the type. Storing it in the control block is what allows that.\n\n---\n\n# The Aliasing Constructor\n\n`shared_ptr` has a constructor that takes two arguments: an existing `shared_ptr` (to share ownership of) and a raw pointer (to expose as the value). The result owns whatever the first argument owned, but `get()` returns the second.\n\nThis is useful for handing out a `shared_ptr` to a member of a larger object without giving up control of the outer object's lifetime.\n\n\n```cpp\n#include \n#include \n#include \n\nstruct Order {\n std::string customerEmail;\n double total;\n};\n\nint main() {\n auto order = std::make_shared(Order{\"a@example.com\", 89.97});\n\n // Share ownership of the Order, but the pointer \"looks like\" the email string.\n std::shared_ptr email(order, &order->customerEmail);\n\n std::cout << \"Email: \" << *email << std::endl;\n std::cout << \"Strong count: \" << order.use_count() << std::endl;\n\n order.reset();\n // The Order is still alive because `email` keeps the control block strong-count > 0.\n std::cout << \"After order.reset, email still: \" << *email << std::endl;\n return 0;\n}\n```\n\n\nThe `email` `shared_ptr` shares the same control block as `order`, even though it dereferences to the string. The order survives until both `shared_ptr`s are gone. Use this rarely and only when you really need a `shared_ptr` to part of an object whose whole lifetime you're already managing.\n\n---\n\n# Cost Compared with `unique_ptr`\n\n`std::unique_ptr` is one pointer wide, has zero runtime overhead beyond a function call to its deleter at destruction, and supports no copying. `std::shared_ptr` pays for what it offers.\n\n\n| Property | `unique_ptr` | `shared_ptr` |\n|----------|------------------|------------------|\n| Size | One pointer | Two pointers |\n| Copy | Disabled | Allowed; atomic increment on the strong count |\n| Move | Cheap pointer swap | Cheap pointer swap (no atomic op) |\n| Destruction | Direct destructor + deleter call | Atomic decrement; if zero, destroy object; if weak count also zero, free control block |\n| Extra heap allocation | None | One for the control block (avoided by `make_shared`, which fuses object + block) |\n| Deleter location | Part of the type | Type-erased inside the control block |\n| Thread-safe refcount | N/A | Yes |\n\n\n\n> **INFO**\n>\n> **Cost:** Every copy of a `shared_ptr` and every destruction touches an atomic counter, even on the single-threaded path. The atomic op is cheap in absolute terms but not free. If you don't need shared ownership, use `unique_ptr` and you avoid the entire control block.\n\n\nThe rule of thumb most teams follow: default to `unique_ptr`. Reach for `shared_ptr` only when ownership is genuinely shared and there's no single component that can outlive all the others.\n\n---\n\n# Reassignment, `reset`, and the Order of Operations\n\n`reset()` does two things in order: it drops the current object (decrementing the strong count, possibly destroying the object) and then optionally adopts a new one. Assignment from another `shared_ptr` does the same, with the new ownership coming from the right-hand side.\n\n\n```cpp\n#include \n#include \n#include \n\nclass Product {\npublic:\n Product(std::string name) : name_(std::move(name)) {\n std::cout << \"ctor: \" << name_ << std::endl;\n }\n ~Product() { std::cout << \"dtor: \" << name_ << std::endl; }\n const std::string& name() const { return name_; }\n\nprivate:\n std::string name_;\n};\n\nint main() {\n auto p = std::make_shared(\"USB Cable\");\n p = std::make_shared(\"Mouse Pad\");\n p.reset();\n std::cout << \"after reset, p is \"\n << (p ? \"non-null\" : \"null\") << std::endl;\n return 0;\n}\n```\n\n\nThe assignment built the new `Mouse Pad` first, then dropped the old `USB Cable`. The `reset()` at the end dropped the `Mouse Pad`. The print order tells you exactly when each destructor ran, which is often the easiest way to confirm your mental model of who owns what.\n\n---\n\n# What This Chapter Doesn't Cover\n\n`shared_ptr` interacts with several other features that get their own chapters in this section.\n\n- **`std::weak_ptr`** is a non-owning observer that lets you check whether the object is still alive without keeping it alive yourself.\n- **`std::make_shared`** has additional nuances (exception safety, layout, when it's not the right choice).\n- **Circular references** are the main pitfall: two `shared_ptr`s that own each other create a cycle that the reference count alone cannot break. `weak_ptr` is the fix.\n\nThe simple rule for now: if you find yourself wanting `A` and `B` to refer to each other and both be `shared_ptr`, hold off and reach for `weak_ptr` on one side before designing it that way.\n\n---\n\n# Summary\n\n- `std::shared_ptr` models shared ownership using reference counting: copies bump the count, destruction drops it, and the last one to die frees the object.\n- Each `shared_ptr` is two pointers (object and control block). The control block holds the strong count, weak count, deleter, and allocator, and is shared among all `shared_ptr`s pointing at the same object.\n- `std::make_shared(args...)` is the preferred constructor because it fuses the object and the control block into one allocation and avoids the leak window of `shared_ptr(new T(...))`.\n- Member functions worth knowing: `use_count()`, `reset()`, `get()`, `operator*`, `operator->`, `operator bool()`. `unique()` is deprecated in C++17 and removed in C++20; use `use_count() == 1` instead.\n- The reference counts are atomic, but the pointed-to object is not, and a single `shared_ptr` variable mutated from multiple threads is still a data race. Use `std::atomic>` for that case.\n- Custom deleters live in the control block, so they don't change the static type of the `shared_ptr`. The aliasing constructor lets one `shared_ptr` own object X while exposing a pointer into a part of X.\n- Compared with `unique_ptr`, `shared_ptr` costs an extra pointer, an extra allocation (without `make_shared`), and atomic operations on copy and destruction. Default to `unique_ptr` and reach for `shared_ptr` only when ownership is genuinely shared.\n\nThe next chapter, **`std::weak_ptr`**, introduces a non-owning companion to `shared_ptr`. It lets you observe an object without keeping it alive, which is the missing piece for breaking cycles and implementing caches and parent-back-pointers cleanly.","pageType":"cpp"}

std::shared_ptr

Get Premium