Smart Pointers in C++: The Complete Guide

Every C++ developer learns about unique_ptr and shared_ptr. But most tutorials skip the part that actually matters in production: when each one costs you performance, and why.

---

The One Rule

Before anything else, memorize this:

Who owns this resource?
├── One owner         → std::unique_ptr  (DEFAULT)
├── Multiple owners   → std::shared_ptr  (RARE)
├── Non-owning observer →
│   ├── Of shared_ptr → std::weak_ptr
│   └── Of anything   → raw pointer or reference
└── C API resource    → std::unique_ptr + custom deleter

If you’re unsure, start with unique_ptr. You’re right 90% of the time.

---

unique_ptr — The One You Should Use Everywhere

unique_ptr expresses sole ownership. One pointer owns the object. When it goes out of scope, the object is deleted. No questions asked.

Why It’s Zero-Cost

static_assert(sizeof(std::unique_ptr<int>) == sizeof(int*));  // Both 8 bytes

That’s not a simplification — unique_ptr is literally the same size as a raw pointer. The compiler optimizes away all the abstraction. The destructor call becomes a single delete instruction. The operator-> compiles to a direct dereference. Zero overhead.

This is why I used raw pointers with a custom arena allocator in my HFT Matching Engine — but for any normal application, unique_ptr gives you that same raw pointer performance with automatic cleanup.

The Move-Only Trick

auto p1 = std::make_unique<Order>(10000, 50);
auto p2 = p1;              // ❌ COMPILE ERROR! Can't copy unique_ptr
auto p2 = std::move(p1);   // ✅ Ownership transferred. p1 is now null.

This is a compile-time guarantee that only one pointer owns the object. No reference counting. No runtime checks. The language enforces it.

Factory Pattern

This is the most common use case — and the one you should use in every project:

std::unique_ptr<Strategy> create_strategy(const Config& cfg) {
    if (cfg.type == "momentum")
        return std::make_unique<MomentumStrategy>(cfg);
    else
        return std::make_unique<MeanReversionStrategy>(cfg);
}
 
auto strategy = create_strategy(config);
strategy->execute(tick);  // Polymorphic call, zero overhead
// Automatically deleted when strategy goes out of scope

Compare this to the raw pointer version:

Strategy* create_strategy(const Config& cfg) {
    return new MomentumStrategy(cfg);  // Who deletes this? When? What if we throw?
}

Same performance. But the raw pointer version leaks memory if you forget to delete. The unique_ptr version literally cannot leak.

Custom Deleters (C API Integration)

This is where unique_ptr really shines — wrapping C resources:

// File handle — auto-closes when done
auto file = std::unique_ptr<FILE, decltype(&fclose)>(
    fopen("data.csv", "r"), fclose
);
// No need to remember fclose() — RAII handles it
 
// Database connection — auto-disconnects
auto db = std::unique_ptr<PGconn, decltype(&PQfinish)>(
    PQconnectdb("host=localhost"), PQfinish
);

Every C library that gives you a handle + cleanup function can be wrapped in unique_ptr. Memory leaks become impossible.

---

shared_ptr — The One You Probably Don’t Need

shared_ptr uses reference counting — it tracks how many pointers share ownership. The object is deleted when the last one dies.

How It Works Internally

auto sp1 = std::make_shared<Order>(100.0, 500);
auto sp2 = sp1;  // Reference count: 2

┌─────────────────────────┐
│ Control Block            │
│   strong_count = 2       │  ← Atomic! (thread-safe)
│   weak_count   = 0       │
│ ┌─────────────────────┐ │
│ │ Order object         │ │  ← make_shared puts both in ONE allocation
│ │   price = 100.0      │ │
│ │   qty   = 500        │ │
│ └─────────────────────┘ │
└─────────────────────────┘

The Hidden Costs

Here’s what tutorials don’t tell you:

Cost #1: Size — 2x larger than unique_ptr

sizeof(std::unique_ptr<int>) == 8;   // One pointer
sizeof(std::shared_ptr<int>) == 16;  // Two pointers (object + control block)

Cost #2: Atomic operations on every copy and destroy

auto sp2 = sp1;  // Atomic increment of strong_count (~10-20 ns)
// In a tight loop with millions of copies, this adds up FAST

Cost #3: Cache line bouncing in multithreaded code

When two threads copy/destroy shared_ptr to the same object, they both need to atomically modify the same strong_count integer. This causes the cache line containing the control block to bounce between CPU cores — a hidden performance killer in concurrent systems.

This is why you’ll never see shared_ptr in HFT engines or game engines on the hot path.

When shared_ptr IS the Right Choice

Genuine shared ownership is rare, but it exists:

// Observer pattern: multiple widgets reference the same data
class Dashboard {
    std::shared_ptr<MarketData> data_;   // Dashboard shares data...
};
 
class AlertSystem {
    std::shared_ptr<MarketData> data_;   // ...with AlertSystem
};
// Data is freed when BOTH Dashboard and AlertSystem are destroyed

If you can’t answer “who should delete this object?” with a single clear answer, shared_ptr is correct. But if you can — use unique_ptr.

---

weak_ptr — The Cycle Breaker

weak_ptr observes a shared_ptr without incrementing the reference count. It exists for one reason: preventing circular references.

The Classic Memory Leak

class A {
    std::shared_ptr<B> b;  // A → B (strong)
};
class B {
    std::shared_ptr<A> a;  // B → A (strong) ← CYCLE!
};
 
auto a = std::make_shared<A>();
auto b = std::make_shared<B>();
a->b = b;  // b: strong_count = 2
b->a = a;  // a: strong_count = 2
// Both go out of scope → strong_count drops to 1 → neither deleted → LEAK!

The Fix

class B {
    std::weak_ptr<A> a;  // B → A (weak) — doesn't prevent A's destruction
};
// Now when a goes out of scope → strong_count = 0 → A destroyed → b freed

Safe Access Pattern

std::weak_ptr<Order> wp = some_shared_ptr;
 
if (auto locked = wp.lock()) {
    // locked is a shared_ptr — object is alive
    std::cout << locked->price << "\n";
} else {
    // Object has been destroyed
}

Real Use Case: Cache

class PriceCache {
    std::unordered_map<std::string, std::weak_ptr<PriceData>> cache_;
 
public:
    std::shared_ptr<PriceData> get(const std::string& symbol) {
        if (auto it = cache_.find(symbol); it != cache_.end()) {
            if (auto sp = it->second.lock()) return sp;  // Cache hit
            cache_.erase(it);  // Expired — clean up
        }
        auto data = std::make_shared<PriceData>(fetch(symbol));
        cache_[symbol] = data;
        return data;
    }
};

The cache holds weak_ptr, so it doesn’t keep data alive unnecessarily. When no one else references a price, it’s automatically freed and the cache entry becomes expired.

---

The Parameter Passing Cheat Sheet

This is the part most people get wrong:

// ✅ Function just READS data — pass by const reference
void print(const Order& order);
 
// ✅ Function MODIFIES data — pass by reference
void update(Order& order);
 
// ✅ Function TAKES ownership — pass unique_ptr by value
void consume(std::unique_ptr<Order> order);
 
// ✅ Function SHARES ownership — pass shared_ptr by value
void share(std::shared_ptr<Order> order);
 
// ❌ DON'T do this — pointless indirection
void f(const std::unique_ptr<Order>& p);  // Just use const Order&
void f(const std::shared_ptr<Order>& p);  // Just use const Order&

The rule: Smart pointers in function signatures mean ownership semantics. If the function doesn’t change ownership, just pass const T&.

---

Performance Summary

	unique_ptr	shared_ptr	Raw pointer
Size	8 bytes	16 bytes	8 bytes
Dereference	0 ns	0 ns	0 ns
Copy	❌ (compile error)	10-20 ns (atomic)	0 ns
Move	0 ns	0 ns	0 ns
Destroy	~1 ns (delete)	~10 ns (atomic + delete)	manual
Thread safety	N/A	Control block only	N/A
Use when	Default	Shared ownership	Performance-critical hot paths

---

TL;DR

1. Use unique_ptr by default. It’s zero-cost and prevents leaks.
2. Use shared_ptr only for genuine shared ownership. It’s not free — atomic ops on every copy.
3. Use weak_ptr to break cycles and for caches.
4. Pass by const T& in function parameters — not by smart pointer, unless you’re transferring ownership.
5. In hot paths (game loops, HFT matching, real-time audio): profile first, but consider arena allocators with raw pointers if shared_ptr atomics show up in your profile.

---

Follow me for weekly deep dives into C++ systems programming, low-latency architecture, and high-performance computing.

Tags: #cpp #smart-pointers #memory-management #performance #systems-programming