Intuition The core idea (WHY smart pointers exist)A raw pointer (T*) is just a number — an address. It tells you where a thing lives but says nothing about who owns it or when to delete it . So you must delete by hand, and humans forget → memory leaks , double-frees, dangling pointers.
A smart pointer is a tiny object that wraps a raw pointer and ties the object's lifetime to scope . When the smart pointer dies (goes out of scope), its destructor runs delete for you. This is RAII (Resource Acquisition Is Initialization): the resource lives exactly as long as the object that manages it.
Worked example Why raw pointers leakvoid f () { int* p = new int ( 42 ); if ( something ()) return ; // ⚠️ leak! we never delete p delete p; } Why this step? Every new needs a matching delete. Any early return, throw, or break between them skips the delete. Smart pointers move that delete into a destructor, which always runs on scope exit.
unique_ptr<T>
A smart pointer that owns its object exclusively . There is exactly one owner at a time. It is non-copyable but movable — ownership can be transferred but never duplicated .
Intuition WHY non-copyableIf two unique_ptrs pointed to the same object, both destructors would call delete → double-free (crash). To make that impossible, the copy constructor is = deleted. You can only move ownership, which leaves the source empty (nullptr).
unique_ptr
#include <memory> auto p = std :: make_unique < int >( 42 ); // preferred: exception-safe std ::cout << * p; // 42 — dereference like a pointer
auto q = std :: move (p); // ownership moves p -> q // now p == nullptr, q owns the int
if ( ! p) std ::cout << "p is empty" ; // true Why make_unique? It does the new and constructs the unique_ptr in one call → no raw new floating around, and it's exception-safe.
Why std::move? Copy is forbidden; move casts to an rvalue so the move-constructor runs and transfers the pointer, nulling the source.
Worked example Returning ownership from a factorystd :: unique_ptr < Widget > makeWidget () { return std :: make_unique < Widget >(); // moved out automatically } Why this step? Returning by value moves the unique_ptr out — perfect for factories; the caller becomes the sole owner.
shared_ptr<T>
A smart pointer where many owners share one object. It keeps a reference count ; the object is deleted only when the count drops to zero (i.e. the last owner dies).
Intuition WHY a reference countSometimes you genuinely don't know who outlives whom (e.g. a node referenced by several lists). You want the object alive as long as anyone needs it . So we count owners : each copy +1, each destruction −1; delete at 0.
Worked example Reference counting in actionauto a = std :: make_shared < int >( 7 ); // strong = 1 { auto b = a; // copy → strong = 2 std ::cout << a. use_count (); // 2 } // b dies → strong = 1 std ::cout << a. use_count (); // 1 // a dies at end of scope → strong = 0 → int deleted Why make_shared? It allocates the object and the control block in one memory block → faster, one allocation, better cache locality (vs shared_ptr<int>(new int(7)) which does two allocations).
weak_ptr exists (the cycle problem)
Reference counting fails on cycles. If A holds a shared_ptr to B and B holds a shared_ptr to A, then even after you drop your handles, each still keeps the other's strong count at 1. Count never reaches 0 → both leak forever.
weak_ptr<T>
A non-owning observer of a shared_ptr-managed object. It does not raise the strong count, so it does not keep the object alive. To use it you must lock() it, which returns a shared_ptr (or empty if the object is already gone).
Worked example Breaking a parent↔child cyclestruct Node { std ::shared_ptr < Node > next; // owns the next node std ::weak_ptr < Node > prev; // ⬅ weak: observes, does NOT own };
auto n1 = std :: make_shared < Node >(); auto n2 = std :: make_shared < Node >(); n1->next = n2; // n2 strong = 2 n2->prev = n1; // n1 strong = 1 (weak doesn't count!) // when n1, n2 go out of scope → both freed. No leak. ✅ Why make prev weak? It expresses "I refer back but I don't own my parent." That keeps one direction non-counting, so the cycle's strong count can hit 0.
Worked example Safely using aweak_ptr
std ::weak_ptr <int> w = somePtr; if ( auto s = w. lock ()) { // try to get a shared_ptr std ::cout << * s; // safe: object still alive } else { std ::cout << "expired" ; // object already deleted } Why lock() and not raw deref? Between checking and using, the object could be deleted by another owner. lock() atomically either pins the object (strong++) or tells you it's gone — no dangling access.
Common mistake Steel-manned common errors(1) "Two shared_ptrs from the same raw pointer share the count."
Why it feels right: they point to the same object, surely they coordinate.
Reality: shared_ptr<T> a(raw); shared_ptr<T> b(raw); creates two separate control blocks → both think they're the sole owner → double-free . Fix: create one shared_ptr and copy it, or use make_shared.
(2) "weak_ptr lets me *w directly."
Why it feels right: it points to the object.
Reality: weak_ptr has no * / ->. Fix: call w.lock() and check the result.
(3) "Copying a unique_ptr should just work."
Why it feels right: other pointers copy fine.
Reality: copy is deleted (would double-free). Fix: std::move to transfer ownership.
(4) "make_shared and shared_ptr<T>(new T) are identical."
Reality: make_shared = one allocation (object + control block together); the other = two allocations and is not exception-safe in some call patterns. Fix: prefer make_shared/make_unique.
Recall Feynman: explain to a 12-year-oldImagine a library book. A unique_ptryou can hold — when you leave, the book is returned automatically. You can hand it to a friend (move), but then you don't have it anymore. A shared_ptrzero , the book goes back on the shelf (deleted). A weak_ptrwhere the book is, but didn't actually borrow it — they don't add a tick. Before reading it, they must check "is the book still here?" (lock()). The weak person stops two friends from accidentally keeping a book forever just by pointing at each other (a cycle).
Mnemonic Remember the three"U-S-W: Use Single ownership, Share with a counter, Weakly watch to break cycles."
Or: U nique = U no owner, S hared = S um of owners, W eak = W atch only.
What does unique_ptr guarantee about ownership? Exactly one owner; it is non-copyable, only movable (ownership transfers, never duplicates).
Why is unique_ptr non-copyable? Two copies would both delete the same object → double-free; copy ctor is =deleted, so you must std::move.
What does make_unique / make_shared give you over new? No raw new, exception safety; make_shared also does a single allocation for object + control block.
What does a shared_ptr store? A pointer to the object plus a pointer to a control block holding the strong count, weak count, and deleter.
When is a shared_ptr-managed object deleted? When the strong (owner) count reaches 0; the control block frees when strong0 AND weak 0.
What happens to use_count() when you copy a shared_ptr? It increases by 1; it decreases by 1 when a copy is destroyed or reset.
What problem does weak_ptr solve? Reference cycles — two shared_ptrs pointing at each other never reach count 0 and leak; weak_ptr observes without raising the strong count.
How do you safely access the object behind a weak_ptr? Call lock(); it returns a shared_ptr if still alive, or an empty one if expired.
Does weak_ptr increase the strong reference count? No — it only affects the weak count, so it never keeps the object alive.
Default smart pointer to reach for? unique_ptr — cheapest and clearest; upgrade to shared_ptr only when ownership is truly shared.
Why is constructing two shared_ptrs from the same raw pointer a bug? They create separate control blocks → each thinks it's sole owner → double-free.
RAII — the principle smart pointers implement (lifetime = scope).Move-semantics — why unique_ptr transfers via std::move.Rule-of-Zero — using smart pointers means you rarely write destructors.Memory-leaks-and-dangling-pointers — the bugs these prevent.Reference-counting — the algorithm inside shared_ptr.Garbage-collection — contrast: deterministic destruction vs GC.
std::move transfers ownership
Intuition Hinglish mein samjhoDekho, raw pointer (T*) sirf ek address hota hai — woh batata hai cheez kahaan hai, par ye nahi batata ki uska owner kaun hai aur delete kab karna hai. Isliye humein khud delete likhna padta hai, aur agar beech mein koi return ya throw aa gaya toh memory leak ho jaati hai. Smart pointer ek chhota object hai jo raw pointer ko wrap karta hai aur jab woh object scope se bahar jaata hai, uska destructor automatically delete chala deta hai. Yahi RAII ka funda hai.
unique_ptr ka matlab hai akela maalik — sirf ek owner. Isko copy nahi kar sakte (warna double-free crash ho jaaye), sirf std::move se ownership transfer kar sakte ho. Yeh sabse sasta aur clear hai, isliye default yahi use karo. shared_ptr tab use karo jab sach mein kai log ek hi object share kar rahe ho — yeh ek reference count rakhta hai: har copy par +1, har destruction par −1, aur jab count zero ho jaaye tab object delete. Hamesha make_shared use karo kyunki woh ek hi allocation mein object aur control block dono bana deta hai.
weak_ptr ka kaam hai cycle todna . Maan lo A, B ko shared_ptr se pakadta hai aur B, A ko — toh dono ek dusre ki count 1 par rakh dete hain, kabhi 0 nahi hoti, dono leak. Solution: ek direction ko weak_ptr bana do — woh observe karta hai par count nahi badhata, toh object alive nahi rakhta. weak_ptr ko seedha * se access nahi karte; pehle lock() karo, agar object zinda hai toh shared_ptr milega, warna empty — bilkul safe. Yaad rakho: U-S-W — Unique single owner, Shared with counter, Weak sirf watch.
