{"title":"Smart Pointers Overview","description":null,"content":"A smart pointer is a class that wraps a raw pointer and adds automatic lifetime management: when the smart pointer goes out of scope, its destructor frees the memory the pointer was managing. That single change closes the door on most of the bugs that raw `new` and `delete` are famous for, including memory leaks, double-free, and dangling pointers from forgotten cleanup. This chapter introduces the idea, the standard library types that implement it (`std::unique_ptr`, `std::shared_ptr`, `std::weak_ptr`), and the trade-offs against raw pointers.\n\n---\n\n# The Problem with Raw `new` and `delete`\n\nRaw pointer ownership is a manual contract. Every `new` has to be paired with exactly one `delete`, on every code path, including exception paths. Get it wrong and the program either leaks memory or frees the same block twice. The shape of the bug is the same in each case:\n\n\n```cpp\n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nvoid process(int discountCode) {\n Product* p = new Product{\"Wireless Mouse\", 24.99};\n\n if (discountCode < 0) {\n return; // BUG: forgot to delete p\n }\n\n p->price *= (1.0 - discountCode / 100.0);\n std::cout << p->name << \": $\" << p->price << std::endl;\n\n delete p;\n}\n\nint main() {\n process(-1); // leaks\n process(10); // works\n return 0;\n}\n```\n\n\nThe function allocates a `Product` on the heap. If the discount code is invalid, it returns early without cleaning up. The pointer `p` goes out of scope, but the memory it pointed at is still allocated, with no remaining reference to free it. That memory is leaked for the rest of the program's run.\n\nThree classes of bug appear in raw-pointer code:\n\n**Memory leak.** A `new` without a matching `delete`. The program holds onto memory it can no longer reach. Over time, leaks add up to processes that grow without bound.\n\n**Double-free.** The same address gets passed to `delete` twice. The second free corrupts the heap's internal bookkeeping. The program might crash immediately or, worse, run for a while and then crash somewhere unrelated.\n\n**Dangling pointer (use-after-free).** A pointer holds an address that has already been freed. Reading or writing through it accesses memory that may have been reused for something else entirely.\n\nThree diagrams help see what is going on. First, the leak:\n\n\n```mermaid\nflowchart LR\n SCOPE[Function returns]:::red --> P[Pointer p destroyed]:::red\n P --> HEAP[Heap memory]:::orange\n HEAP --> LOST[Still allocated
no pointer reaches it]:::red\n\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nWhen `process` returns early, `p` is gone but the memory it pointed at is still allocated. The address is lost, so nothing can free it.\n\nSecond, the double-free:\n\n\n```mermaid\nflowchart LR\n A[Pointer a]:::cyan --> M[Heap block]:::orange\n B[Pointer b]:::cyan --> M\n A --> D1[delete a
frees block]:::red\n D1 --> D2[delete b
frees same block again]:::red\n D2 --> CORRUPT[Heap corruption]:::red\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nTwo pointers, one block. The first `delete` frees the block. The second `delete` corrupts the heap's free list, often causing a crash on the next allocation.\n\nThird, the dangling pointer:\n\n\n```mermaid\nflowchart LR\n P[Pointer p]:::cyan --> M[Heap block]:::orange\n D[delete p]:::red --> X[Block freed]:::red\n P --> X\n P --> USE[*p still happens
reads garbage or crashes]:::red\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe pointer is still in scope, but its target is gone. Dereferencing it produces whatever the heap allocator has done with the memory since.\n\nAll three bugs share one root: the human has to remember to free at the right time, on every path. Smart pointers move that responsibility from the human to the type system.\n\n**Quick Check:** Which of these patterns most often produces a memory leak in raw-pointer code?\n\n- A) Calling `delete` twice on the same pointer\n- B) An early `return` between `new` and the matching `delete`\n- C) Calling `delete` on a `nullptr`\n- D) Dereferencing a freed pointer\n\n

Answer

\n\n**B.** An early return (or a thrown exception) between `new` and `delete` skips the cleanup. The pointer goes out of scope, the address is lost, and the memory cannot be reclaimed. A is double-free, C is harmless (`delete nullptr` is defined to do nothing), and D is use-after-free.\n\n

\n\n---\n\n# RAII: The Idea Smart Pointers Implement\n\nThe C++ pattern that fixes this is called RAII, short for \"Resource Acquisition Is Initialization\". The idea is older than the name: tie the lifetime of a resource (memory, file handle, socket, lock) to the lifetime of an object on the stack. When the stack object is destroyed, its destructor releases the resource. The compiler runs destructors automatically when scopes end, even on exceptions, so the cleanup happens regardless of how the function exits.\n\nA small hand-written RAII wrapper for an `int` on the heap:\n\n\n```cpp\n#include \n\nclass IntHolder {\npublic:\n IntHolder(int value) : ptr(new int(value)) {}\n ~IntHolder() { delete ptr; }\n\n int get() const { return *ptr; }\n\nprivate:\n int* ptr;\n};\n\nint main() {\n IntHolder a(42);\n std::cout << \"Value: \" << a.get() << std::endl;\n return 0;\n // a's destructor runs, delete ptr happens automatically\n}\n```\n\n\n**Output:**\n\n\n```shell\nValue: 42\n```\n\n\nThe destructor runs when `a` goes out of scope. The `delete` is no longer something the programmer has to remember. Even if a later line threw an exception, the destructor would still run as the stack unwound, and the memory would still be freed.\n\nThis wrapper is missing a few pieces (it cannot be safely copied, for one), but it shows the shape: a class owns a resource, and its destructor releases it. Smart pointers are this wrapper, written correctly and generalized to any type.\n\n\n```mermaid\nflowchart LR\n SCOPE_IN[Scope starts]:::cyan --> CREATE[Smart pointer
owns heap memory]:::orange\n CREATE --> USE[Use freely
like a raw pointer]:::green\n USE --> SCOPE_OUT[Scope ends]:::cyan\n SCOPE_OUT --> DTOR[Destructor runs]:::orange\n DTOR --> FREE[Memory freed
automatically]:::green\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 smart pointer is a stack object. It owns a heap allocation. When it goes out of scope, the destructor frees the heap memory. The whole thing happens without explicit cleanup at the call site.\n\n---\n\n# The Three Standard Smart Pointers\n\nThe C++ standard library provides three smart pointer class templates, all in the `` header. Each represents a different ownership model.\n\n\n```cpp\n#include \n```\n\n\nThe header has been part of the standard library since C++98 (for `auto_ptr`, now removed) and modern usage starts with C++11, which added `unique_ptr`, `shared_ptr`, and `weak_ptr`. `` is a default include in modern C++ projects.\n\n\n| Smart pointer | Ownership model | Cost vs raw pointer | When to use |\n|---------------|-----------------|---------------------|-------------|\n| `std::unique_ptr` | Exclusive: exactly one owner at a time | Zero size overhead | The default. Use when one piece of code owns the object. |\n| `std::shared_ptr` | Shared: many owners, freed when the last one disappears | Reference count (heap-allocated control block) | When ownership is genuinely shared across multiple parts of the program. |\n| `std::weak_ptr` | Non-owning observer of a `shared_ptr`-owned object | Same control block as `shared_ptr` | To observe a shared object without keeping it alive. Breaks cycles. |\n\n\nA short example of each, to show the shape.\n\n### `std::unique_ptr` (Exclusive Ownership)\n\n\n```cpp\n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nint main() {\n std::unique_ptr mouse = std::make_unique(\"Mouse\", 24.99);\n std::cout << mouse->name << \": $\" << mouse->price << std::endl;\n return 0;\n // mouse goes out of scope here, destructor runs, Product is deleted\n}\n```\n\n\n**Output:**\n\n\n```shell\nMouse: $24.99\n```\n\n\nA `unique_ptr` cannot be copied. There is exactly one owner of the `Product`. The `unique_ptr` can be moved into another `unique_ptr` (transferring ownership), but never duplicated. This rules out double-free and most use-after-free bugs in code that respects the ownership boundary.\n\n`std::make_unique(...)` is the recommended way to create a `unique_ptr`. It allocates and constructs the object in one expression, which is safer than `unique_ptr(new Product(...))`.\n\n### `std::shared_ptr` (Shared Ownership)\n\n\n```cpp\n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nint main() {\n std::shared_ptr a = std::make_shared(\"Mouse\", 24.99);\n std::shared_ptr b = a; // both now own the Product\n std::shared_ptr c = a; // three owners\n\n std::cout << \"Owners: \" << a.use_count() << std::endl;\n return 0;\n // a, b, c all go out of scope; the last one's destructor frees the Product\n}\n```\n\n\n**Output:**\n\n\n```shell\nOwners: 3\n```\n\n\nA `shared_ptr` keeps a reference count: how many `shared_ptr` objects refer to the same heap allocation. Copying a `shared_ptr` increments the count; destroying one decrements it. When the count reaches zero, the destructor frees the object.\n\nThe reference count lives in a separately-allocated control block alongside the object, so a `shared_ptr` is roughly the size of two raw pointers, and creating one has the cost of an extra allocation (unless `make_shared` is used, which combines the two allocations into one).\n\n### `std::weak_ptr` (Non-Owning Observer)\n\n\n```cpp\n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n};\n\nint main() {\n std::weak_ptr observer;\n\n {\n std::shared_ptr owner = std::make_shared(\"Mouse\");\n observer = owner;\n\n if (auto lock = observer.lock()) {\n std::cout << \"Still alive: \" << lock->name << std::endl;\n }\n } // owner goes out of scope, Product is destroyed\n\n if (auto lock = observer.lock()) {\n std::cout << \"Still alive\" << std::endl;\n } else {\n std::cout << \"Object is gone\" << std::endl;\n }\n return 0;\n}\n```\n\n\n**Output:**\n\n\n```shell\nStill alive: Mouse\nObject is gone\n```\n\n\nA `weak_ptr` holds a non-owning reference to an object managed by `shared_ptr`. It does not contribute to the reference count, so the object can be freed even while a `weak_ptr` still exists. To use the pointed-to object, the program calls `lock()`, which returns a `shared_ptr` that is either valid (if the object still exists) or empty (if it has been destroyed).\n\n`weak_ptr` is the standard solution to cycles in shared ownership graphs, where two `shared_ptr` objects pointing at each other would never reach zero references.\n\n\n```mermaid\nflowchart LR\n UNIQUE[unique_ptr]:::cyan --> EXCL[One owner
cannot copy]:::orange\n SHARED[shared_ptr]:::cyan --> MULTI[N owners
ref counted]:::orange\n WEAK[weak_ptr]:::cyan --> OBS[Observer of shared_ptr
does not own]:::orange\n\n EXCL --> FREE1[Freed when owner dies]:::green\n MULTI --> FREE2[Freed when last owner dies]:::green\n OBS --> NOFREE[Never frees on its own]:::red\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 classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe three types form a layered model. `unique_ptr` is the default. `shared_ptr` fits when ownership is genuinely shared. `weak_ptr` observes without owning, and it only makes sense in combination with `shared_ptr`.\n\n**Quick Check:** A factory function builds a `Product` and gives it to one caller, which keeps it for the rest of the program. Which smart pointer type fits?\n\n- A) `std::unique_ptr`\n- B) `std::shared_ptr`\n- C) `std::weak_ptr`\n- D) A raw `Product*`\n\n

Answer

\n\n**A.** There is exactly one owner, so `unique_ptr` fits. `shared_ptr` adds reference counting that is not needed. `weak_ptr` does not own anything and cannot be the result of a factory. A raw pointer puts the deletion burden on the caller, which is the problem smart pointers solve.\n\n

\n\n---\n\n# The `` Header\n\nAll three smart pointer types live in ``, along with the `make_unique` and `make_shared` factory functions and a few other utilities.\n\n\n```cpp\n#include \n\nstd::unique_ptr u = std::make_unique(42);\nstd::shared_ptr s = std::make_shared(42);\nstd::weak_ptr w = s;\n```\n\n\n`make_unique` was added in C++14, slightly later than the C++11 introduction of `unique_ptr` itself. Older C++11-only code constructs `unique_ptr` directly with `new`:\n\n\n```cpp\nstd::unique_ptr u(new int(42)); // C++11\nstd::unique_ptr u = std::make_unique(42); // C++14 and later\n```\n\n\nThe `make_unique` form is preferred for two reasons: it is exception-safe in argument lists (the raw `new` form has a known exception-safety hole when used as a function argument), and it avoids repeating the type name. For new code, use `make_unique` and `make_shared` rather than the raw-`new` constructor.\n\nThe `` header also defines several supporting utilities (allocators, `std::allocator_traits`, `std::pointer_traits`, `std::uninitialized_*` algorithms). For everyday code, the three smart pointers and the two `make_*` factory functions are the entire vocabulary.\n\n---\n\n# Smart Pointer vs Raw Pointer: Trade-Offs\n\nSmart pointers do not fit every situation. Raw pointers still have a place; the question is which job each one fits.\n\n\n| Question | Raw pointer | Smart pointer |\n|----------|-------------|---------------|\n| Who owns the object? | The programmer decides, often implicit | The type encodes it |\n| How is the memory freed? | Explicit `delete` somewhere | Automatic, on scope exit |\n| Can it be null? | Yes | Yes |\n| Can it leak? | Yes, on forgotten cleanup | No (almost; cycles in `shared_ptr` can) |\n| Can it dangle? | Yes, easily | Only if used incorrectly (e.g. `get()` then misuse) |\n| Size overhead | One pointer (8 bytes on 64-bit) | `unique_ptr`: same. `shared_ptr`: two pointers + control block |\n| Runtime cost on copy | One pointer copy | `unique_ptr`: cannot copy. `shared_ptr`: atomic increment |\n| Use as function parameter | Common | Common, with conventions (see below) |\n| Use for non-owning reference | Common | Use raw pointer or reference instead |\n\n\nThe key distinction is **ownership versus access**. A smart pointer fits when the type needs to encode \"this object is mine, and when I'm gone, the memory is freed\". A raw pointer (or a reference) fits when the type just needs to point at something that someone else owns.\n\nA common convention in modern C++ codebases:\n\n- A `std::unique_ptr` parameter says \"I take ownership of this object\".\n- A `std::shared_ptr` parameter says \"I become one of the owners of this object\".\n- A `T*` or `T&` parameter says \"I do not own this; I just need to look at it for the duration of this call\".\n\nThat last point is worth unpacking. A function that examines an object for the duration of its call does not need to participate in ownership. Wrapping a raw pointer in `shared_ptr` just to pass it as a parameter would force the caller to wrap its raw pointer, adding cost and obscuring the contract.\n\n\n```cpp\n// Good: ownership transfer\nstd::unique_ptr createProduct(const std::string& name);\n\n// Good: non-owning access\nvoid printProduct(const Product& item);\nvoid printProductOrNothing(const Product* item);\n\n// Usually wrong: forcing ownership on a function that only reads\nvoid printProduct(std::shared_ptr item);\n```\n\n\nThe shared-pointer parameter version still works, but it does extra work (atomic increment and decrement) for no reason. The reference version is cheaper and more truthful about the contract.\n\n---\n\n# When Smart Pointers Are Not the Answer\n\nSmart pointers fit heap-allocated objects whose lifetime needs explicit management. They do not fit every situation.\n\n- **Stack-allocated objects.** A local `Product item{\"Mouse\", 24.99};` does not need a smart pointer at all. The compiler handles the destruction when the scope ends.\n- **Values in containers.** A `std::vector` already manages the lifetime of its elements. Wrapping each element in a `unique_ptr` adds an allocation per element with no benefit, unless the elements are polymorphic and need to be stored as base pointers.\n- **Non-owning observers.** If a function just reads from an object, a `const T&` or `const T*` parameter fits. Passing a `shared_ptr` by value bumps the reference count for no reason.\n- **Performance-critical hot paths.** `shared_ptr` reference counting uses atomic operations, which are not free. In tight loops or low-latency code, a raw pointer (or a reference, or an index) may be measurably faster. `unique_ptr` has no such overhead and remains a good choice.\n- **C interop.** A C API that takes a `T*` cannot take a `unique_ptr` directly. Call `.get()` on the smart pointer to extract the raw pointer for the duration of the call, but do not let the C code take ownership.\n\nThe general rule: **own with smart pointers, pass and look at with raw pointers or references**. Mixing them this way avoids the worst bugs of raw-pointer ownership and the worst overhead of smart-pointer parameters.\n\n**Quick Check:** Three of these are situations where a smart pointer fits. Which one does not?\n\n- A) A factory function that returns a newly-created object to the caller.\n- B) A member field that owns a polymorphic object stored as a base-class pointer.\n- C) A function parameter that just reads a single product to print its name.\n- D) A container of polymorphic objects where each element owns its own state.\n\n

Answer

\n\n**C.** A function that only reads the object should take a `const T&` or `const T*` parameter. Wrapping the argument in a smart pointer for the call adds cost (an atomic increment for `shared_ptr`) or is impossible (`unique_ptr` cannot be copied). The other three are textbook smart-pointer use cases.\n\n

\n\n---\n\n# A Side-by-Side Rewrite\n\nThe leaky example from the beginning of this chapter, rewritten with `std::unique_ptr`:\n\n\n```cpp\n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nvoid process(int discountCode) {\n auto p = std::make_unique(Product{\"Wireless Mouse\", 24.99});\n\n if (discountCode < 0) {\n return; // safe: p's destructor runs and frees the Product\n }\n\n p->price *= (1.0 - discountCode / 100.0);\n std::cout << p->name << \": $\" << p->price << std::endl;\n\n // no explicit delete needed\n}\n\nint main() {\n process(-1);\n process(10);\n return 0;\n}\n```\n\n\n**Output:**\n\n\n```shell\nWireless Mouse: $22.491\n```\n\n\nThree changes from the raw-pointer version:\n\n- `new Product{...}` becomes `std::make_unique(...)`.\n- The `Product*` becomes a `std::unique_ptr`.\n- The `delete p;` line is removed.\n\nThe early `return` no longer leaks. When `p` goes out of scope, its destructor runs, and the `Product` is freed. The same cleanup happens on the normal return path. Both paths are correct without any `delete` written by the programmer.\n\nThe `->` and the null-checking idioms work the same way on a `unique_ptr` as on a raw pointer:\n\n\n```cpp\nif (p) { p->price = 0.0; }\n```\n\n\n`unique_ptr` provides `operator bool` and `operator->`, so the calling code reads almost identically to raw-pointer code. The only difference is that the lifetime is now the smart pointer's job, not the programmer's.\n\n---\n\n# A Worked Example: A Polymorphic Cart\n\nA more realistic example. A shopping cart holds items of different types, each with its own pricing rule. With raw pointers, the cart has to remember to `delete` each item. With `unique_ptr`, the cart manages lifetimes automatically.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nclass Item {\npublic:\n virtual ~Item() = default;\n virtual double price() const = 0;\n virtual std::string label() const = 0;\n};\n\nclass Product : public Item {\npublic:\n Product(std::string name, double basePrice)\n : name_(std::move(name)), basePrice_(basePrice) {}\n\n double price() const override { return basePrice_; }\n std::string label() const override { return name_; }\n\nprivate:\n std::string name_;\n double basePrice_;\n};\n\nclass DiscountedProduct : public Item {\npublic:\n DiscountedProduct(std::string name, double basePrice, double percent)\n : name_(std::move(name)), basePrice_(basePrice), percent_(percent) {}\n\n double price() const override {\n return basePrice_ * (1.0 - percent_ / 100.0);\n }\n std::string label() const override {\n return name_ + \" (\" + std::to_string(static_cast(percent_)) + \"% off)\";\n }\n\nprivate:\n std::string name_;\n double basePrice_;\n double percent_;\n};\n\nint main() {\n std::vector> cart;\n cart.push_back(std::make_unique(\"Mouse\", 24.99));\n cart.push_back(std::make_unique(\"Keyboard\", 49.99, 10.0));\n cart.push_back(std::make_unique(\"USB Cable\", 7.50));\n\n double total = 0.0;\n for (const auto& item : cart) {\n std::cout << item->label() << \": $\" << item->price() << std::endl;\n total += item->price();\n }\n std::cout << \"Total: $\" << total << std::endl;\n\n return 0;\n // cart goes out of scope. Each unique_ptr in it is destroyed,\n // and each owned Item is freed. No explicit delete anywhere.\n}\n```\n\n\n**Output:**\n\n\n```shell\nMouse: $24.99\nKeyboard (10% off): $44.991\nUSB Cable: $7.5\nTotal: $77.481\n```\n\n\nA few details about this example:\n\nThe cart is `std::vector>`. The vector owns the smart pointers, and each smart pointer owns one polymorphic item. When the vector is destroyed (when `main` returns, in this case), it destroys each smart pointer in turn, which destroys each item. No manual cleanup, no leak, no risk of double-free.\n\nThe items are polymorphic, so they are stored by base-class pointer. This is the canonical use case for `unique_ptr` in containers: storing different concrete types behind a common interface. Plain `std::vector` would not work, because `Item` is abstract and cannot be sliced into the vector.\n\nCalls to `item->price()` and `item->label()` use `->` the same way raw pointers do. The dispatch is virtual, so each call lands in the correct derived class. The smart pointer's wrapping is invisible at the call site.\n\n---\n\n# Interview Questions\n\n**Q1: What problems do smart pointers solve that raw pointers do not?**\n\nSmart pointers tie heap-memory lifetime to a stack object's lifetime. The stack object's destructor runs automatically when its scope ends (including during exception unwinding), so the memory is freed on every code path. This eliminates the most common raw-pointer bugs: memory leaks from forgotten `delete`, double-free from confusion about ownership, and use-after-free when one piece of code frees while another still holds the pointer. Smart pointers also document ownership in the type system, so a function signature can declare \"I take ownership\" or \"I share ownership\" instead of leaving it as a comment.\n\n**Q2: When would you use `std::unique_ptr` over `std::shared_ptr`?**\n\nUse `unique_ptr` whenever exactly one piece of code owns the object. It is cheaper (no reference count, no atomic operations, no separately-allocated control block) and clearer about ownership. The default choice for new code is `unique_ptr`. Use `shared_ptr` only when the object genuinely needs multiple owners with independent lifetimes, such as a node shared across a graph or a resource cached by multiple subsystems. Many codebases find that they overuse `shared_ptr`; refactoring to `unique_ptr` usually clarifies the design.\n\n**Q3: What is the purpose of `std::weak_ptr`?**\n\nA `weak_ptr` observes an object owned by `shared_ptr` without contributing to the reference count. Its main use is breaking cycles: if two `shared_ptr` objects point at each other, the reference count never reaches zero and the objects leak. Making one direction a `weak_ptr` lets the cycle decay correctly. A `weak_ptr` is also useful for caches and listener lists, where the observer should not keep the observed object alive but needs a safe way to check whether it still exists. To use the object, call `lock()`, which returns a `shared_ptr` that may be empty if the object has been destroyed.\n\n**Q4: Why is `std::make_unique` preferred over `std::unique_ptr(new T(...))`?**\n\nTwo reasons. First, `make_unique` is exception-safe in function call argument lists. With `f(std::unique_ptr(new T()), g())`, the compiler is allowed to interleave the `new`, the constructor of `unique_ptr`, and the call to `g()` in any order. If `g()` throws between `new T()` and the `unique_ptr` constructor, the allocated memory leaks. `make_unique` packages the allocation and the wrapping into one expression, closing that gap. Second, `make_unique(...)` avoids repeating the type name compared to `unique_ptr(new T(...))`, which keeps long declarations readable. The same logic applies to `make_shared` versus `shared_ptr(new T(...))`.\n\n**Q5: A function only needs to read from a `unique_ptr` to print its name. Should the parameter be `std::unique_ptr`, `const std::unique_ptr&`, `const Product*`, or `const Product&`?**\n\n`const Product&` fits best. The function does not need ownership, and a reference is the cheapest, clearest way to express \"look at this object\". Taking a `unique_ptr` by value would transfer ownership, which is wrong for a read-only operation. Taking it by reference works but ties the caller to using a `unique_ptr` (callers with raw pointers or stack objects could not pass their data). `const Product*` is fine if the parameter may be null. The general rule: function parameters express access, not ownership, unless the function genuinely takes ownership.\n\n---\n\n# Exercises\n\n**Exercise 1:** Convert this leaky function to use `std::unique_ptr`.\n\n\n```cpp\n#include \n\nvoid buyMouse() {\n int* count = new int(1);\n if (*count == 0) {\n return;\n }\n std::cout << \"Bought \" << *count << \" mouse.\" << std::endl;\n delete count;\n}\n```\n\n\n**Expected Output:**\n\n\n```shell\nBought 1 mouse.\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n#include \n\nvoid buyMouse() {\n auto count = std::make_unique(1);\n if (*count == 0) {\n return; // safe: destructor frees count\n }\n std::cout << \"Bought \" << *count << \" mouse.\" << std::endl;\n}\n\nint main() {\n buyMouse();\n return 0;\n}\n```\n\n\nThe early return no longer leaks. The `unique_ptr` destructor frees the `int` automatically.\n\n

\n\n**Exercise 2:** What is the output, and why?\n\n\n```cpp\n#include \n#include \n\nstruct Product {\n std::string name;\n ~Product() { std::cout << \"Destroyed \" << name << std::endl; }\n};\n\nint main() {\n {\n auto a = std::make_unique(\"Mouse\");\n std::cout << \"Inside scope.\" << std::endl;\n }\n std::cout << \"Outside scope.\" << std::endl;\n return 0;\n}\n```\n\n\n**Expected Output:**\n\n\n```shell\nInside scope.\nDestroyed Mouse\nOutside scope.\n```\n\n\n

Solution

\n\nThe `unique_ptr` `a` is declared inside the inner block. When the block ends, `a` goes out of scope, the destructor runs, and `Product`'s destructor prints `Destroyed Mouse`. Only after that does the next line print `Outside scope`.\n\n

\n\n**Exercise 3:** Write a factory function `createProduct(const std::string& name, double price)` that returns a `std::unique_ptr`. Use it in `main`.\n\n**Expected Output:**\n\n\n```shell\nWireless Mouse: $24.99\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nstd::unique_ptr createProduct(const std::string& name, double price) {\n return std::make_unique(Product{name, price});\n}\n\nint main() {\n auto mouse = createProduct(\"Wireless Mouse\", 24.99);\n std::cout << mouse->name << \": $\" << mouse->price << std::endl;\n return 0;\n}\n```\n\n\nThe factory returns ownership to the caller. The caller's `unique_ptr` destructor frees the object at end of scope.\n\n

\n\n**Exercise 4:** Predict the output.\n\n\n```cpp\n#include \n#include \n\nint main() {\n auto a = std::make_shared(42);\n std::cout << \"Count after a: \" << a.use_count() << std::endl;\n\n auto b = a;\n std::cout << \"Count after b: \" << a.use_count() << std::endl;\n\n {\n auto c = a;\n std::cout << \"Count after c: \" << a.use_count() << std::endl;\n }\n\n std::cout << \"Count after c destroyed: \" << a.use_count() << std::endl;\n return 0;\n}\n```\n\n\n**Expected Output:**\n\n\n```shell\nCount after a: 1\nCount after b: 2\nCount after c: 3\nCount after c destroyed: 2\n```\n\n\n

Solution

\n\nEach `shared_ptr` copy increments the reference count. `a` starts at 1. `b = a` makes it 2. `c = a` inside the block makes it 3. When the block ends, `c` is destroyed and the count drops back to 2. The `int` is not freed until the count reaches 0, which would happen after `a` and `b` both go out of scope at the end of `main`.\n\n

\n\n**Exercise 5:** Why does this code crash, and how would you fix it?\n\n\n```cpp\n#include \n#include \n\nstruct Product { int stock; };\n\nint main() {\n Product* raw = new Product{5};\n std::unique_ptr a(raw);\n std::unique_ptr b(raw);\n return 0;\n}\n```\n\n\n

Solution

\n\nBoth `a` and `b` are constructed from the same raw pointer `raw`. When `b` is destroyed at the end of `main`, it deletes the `Product`. Then `a` is destroyed and tries to delete the same `Product` again. This is a double-free, which corrupts the heap and almost always crashes.\n\nThe fix is to never construct two `unique_ptr` objects from the same raw pointer. If shared ownership is needed, use `shared_ptr`. If sole ownership is needed, only one `unique_ptr` should ever own the object:\n\n\n```cpp\nauto a = std::make_unique(Product{5});\nauto b = std::move(a); // a is now empty, b owns the Product\n```\n\n\n

\n\n**Exercise 6:** Fill in the type. A function `cheapest` takes a vector of products and returns the address of the cheapest one. The vector is owned by the caller and stays alive for the duration of the call. What type should the return be?\n\n\n```cpp\n___ cheapest(const std::vector& list);\n```\n\n\n

Solution

\n\n\n```cpp\nconst Product* cheapest(const std::vector& list);\n```\n\n\nThe function does not own the result; it just identifies an element inside the caller's vector. A raw `const Product*` (or a reference, with a sentinel \"not found\" return for empty input) fits the situation. A smart pointer would be wrong here, because the function does not allocate anything. A null pointer can also signal \"the vector was empty\" if needed.\n\n

\n\n**Exercise 7:** Convert this code from raw pointers to smart pointers. Use the most appropriate smart pointer type.\n\n\n```cpp\n#include \n#include \n\nstruct Product { std::string name; double price; };\n\nint main() {\n Product* mouse = new Product{\"Mouse\", 24.99};\n std::cout << mouse->name << \": $\" << mouse->price << std::endl;\n delete mouse;\n return 0;\n}\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n#include \n#include \n\nstruct Product { std::string name; double price; };\n\nint main() {\n auto mouse = std::make_unique(Product{\"Mouse\", 24.99});\n std::cout << mouse->name << \": $\" << mouse->price << std::endl;\n return 0;\n}\n```\n\n\nThere is exactly one owner, so `unique_ptr` is the correct choice. The explicit `delete` is gone; the smart pointer's destructor handles it.\n\n

\n\n**Exercise 8:** Two `shared_ptr` objects manage the same `Product`. The first owner reads the price, then goes out of scope. The second owner reads the price after. Will the `Product` be valid for the second read?\n\n

Solution

\n\nYes. `shared_ptr` keeps a reference count. When the first owner goes out of scope, the count drops from 2 to 1, but the object is not freed because there is still another owner. The second owner can still safely access the `Product`. The object is only freed when the last `shared_ptr` referring to it is destroyed.\n\n

\n\n**Exercise 9:** Why is this code suspect?\n\n\n```cpp\nvoid process(std::shared_ptr item) {\n std::cout << item->name << std::endl;\n}\n```\n\n\n

Solution

\n\nThe function only reads `item->name`. It does not need ownership or shared ownership. Taking `shared_ptr` by value forces every caller to use a `shared_ptr`, and the call itself pays the cost of an atomic increment to bump the reference count. A cleaner signature is `void process(const Product& item)` (or `const Product*` if null is meaningful), which accepts the object by reference without participating in ownership.\n\n

\n\n**Exercise 10:** Name one situation where a `weak_ptr` fits.\n\n

Solution

\n\nA cache that holds references to objects without keeping them alive: the cache maps keys to `weak_ptr`. As long as some other part of the program holds a `shared_ptr` to the resource, the cache can return it via `lock()`. Once no one else holds the resource, the cache's `weak_ptr` becomes empty and `lock()` returns nullptr, so the cache knows to evict the entry.\n\nAnother common use is breaking cycles: a parent node holds `shared_ptr` to its children, but each child holds a `weak_ptr` back to its parent. Without the `weak_ptr`, the parent-child cycle would never drop to zero references and the tree would leak.\n\n

","pageType":"cpp"}

Smart Pointers Overview

Get Premium