unique_ptr, shared_ptr and weak_ptr

C++ gives you three standard ways to point at a heap object, and the choice says who is responsible for deleting it.

std::unique_ptr<T>: one owner. It holds a pointer and deletes the object in its destructor. It cannot be copied, only moved, so there is always exactly one owner. It is the size of a raw pointer (with the default deleter) and costs nothing at run time beyond the delete. This should be the default.

std::shared_ptr<T>: several owners. The object is deleted when the last shared_ptr to it is destroyed. To know when that is, it keeps a reference count in a separately allocated control block.

std::weak_ptr<T>: an observer. It refers to an object managed by shared_ptr without keeping it alive. To use the object you call lock(), which returns a shared_ptr if the object still exists and an empty one if it does not.

Raw pointers and references still have a role: a non-owning parameter that the caller guarantees is alive for the call. Passing const Order& to a function that only reads the order is better than passing any smart pointer.

• Size. A shared_ptr is two pointers: one to the object, one to the control block.
• Allocation. The control block is allocated. std::make_shared<T>() allocates the block and the object together in one allocation; std::shared_ptr<T>(new T) makes two.
• Atomic counting. Every copy increments the strong count and every destruction decrements it. These are atomic read-modify-write operations, because copies may live on different threads. Uncontended, an atomic increment costs a few nanoseconds; contended, when threads on different cores copy the same pointer, the cache line holding the count moves between cores on every operation (Module 5).
• Unpredictable destruction. The object is destroyed on whichever thread drops the last reference, possibly in the middle of a hot path that happened to hold the last copy.

In the order manager above, each hand-off to the risk checker and the gateway copies the pointer: two atomic increments and two decrements per order, on counts that several threads touch. Each order also costs an allocation. Neither is necessary.

Ownership in an order manager is not shared. The manager owns the orders; the risk checker and the gateway look at an order while they process it. That is a single owner with borrowers:

class OrderManager {
    std::vector<Order> orders_;                 // or a pool, see Module 3
public:
    Order& create(const NewOrder& n);           // owner keeps the object
    void route(Order& o, RiskCheck& rc, Gateway& gw) {
        if (rc.check(o)) gw.send(o);            // borrowers take references, no counting
    }
};

If an order must be referred to after the call returns, for example by an exchange acknowledgement that arrives later, use an id or a handle that the manager can look up and validate, rather than a pointer that keeps the object alive (lesson 7).

Genuinely shared, read-mostly data with an unpredictable last user is the classic case: a configuration or a reference-data snapshot that many threads read, replaced occasionally by a new version. Readers hold a shared_ptr to the version they started with; the old version is freed when the last reader finishes. Even then, the readers should take one copy per batch, not one per message.

Two objects that hold shared_ptrs to each other keep each other alive for ever: neither count can reach zero. A session that owns its strategies, where each strategy holds a shared_ptr back to the session, leaks both. The back-reference should be a weak_ptr (or a plain reference, if the owner provably outlives the strategy):

struct Session;
struct Strategy {
    std::weak_ptr<Session> session;                 // does not keep the session alive
    void on_fill() {
        if (auto s = session.lock()) s->record_fill();  // nullptr if the session is gone
    }
};

A detail worth knowing: with make_shared, the object and control block are one allocation, so the memory is not returned until the last weak_ptr is gone as well, even though the object's destructor ran earlier. For large objects observed by long-lived weak pointers, that can matter.