std::shared_ptr

std::shared_ptr<T> — умный указатель с разделяемым владением: несколько shared_ptr могут одновременно владеть одним объектом через общий control block со счётчиком ссылок. Объект уничтожается, когда счётчик доходит до нуля — то есть когда уничтожен последний владеющий shared_ptr.std::shared_ptr<T> is a smart pointer with shared ownership: multiple shared_ptr instances can simultaneously own the same object through a common control block holding a reference count. The object is destroyed when the count reaches zero — that is, when the last owning shared_ptr is destroyed.

std::unique_ptr<Widget> a = std::make_unique<Widget>();
// std::unique_ptr<Widget> b = a; // не компилируется// std::unique_ptr<Widget> b = a; // doesn't compile

std::shared_ptr<Widget> a = std::make_shared<Widget>();
std::shared_ptr<Widget> b = a;  // ок, счётчик = 2// ok, count = 2
// объект удалится, когда оба a и b выйдут из скоупа// the object is destroyed once both a and b go out of scope

Некоторые задачи структурно не укладываются в единоличное владение unique_ptr:Some problems structurally don't fit unique_ptr's sole-ownership model:

shared_ptr хранит два указателя: на сам объект и на control block, который содержит два счётчика — strong count (число shared_ptr) и weak count (число weak_ptr, см. weak-ptr.html), а также deleter и allocator. Инкремент/декремент strong count — атомарная операция (обычно fetch_add/fetch_sub с memory_order_relaxed для inc и memory_order_acq_rel для финального dec) — это и есть источник overhead относительно unique_ptr.shared_ptr stores two pointers: one to the object itself, and one to the control block, which holds two counters — the strong count (number of shared_ptr instances) and the weak count (number of weak_ptr instances, see weak-ptr.html), plus a deleter and an allocator. Incrementing/decrementing the strong count is an atomic operation (typically fetch_add/fetch_sub with memory_order_relaxed for increment and memory_order_acq_rel for the final decrement) — this is the source of overhead relative to unique_ptr.

auto p1 = std::make_shared<Widget>(); // одна аллокация: объект + control block вместе// one allocation: object + control block together
auto p2 = p1;                          // atomic increment strong count → 2// atomic increment of strong count → 2
p1.reset();                            // atomic decrement → 1, p1 = nullptr// atomic decrement → 1, p1 = nullptr
// p2 всё ещё владеет объектом, объект жив// p2 still owns the object, the object is alive
// когда p2 тоже уничтожится — decrement → 0 → delete объекта// once p2 is also destroyed — decrement → 0 → the object is deleted

std::cout << p2.use_count(); // текущее значение strong count (только для диагностики,// the current strong count value (for diagnostics only,
                              // не для логики — race между чтением и concurrent copy/reset)// not for logic — a race exists between the read and a concurrent copy/reset)

// std::shared_ptr<Widget>(new Widget()) — две отдельные аллокации// std::shared_ptr<Widget>(new Widget()) — two separate allocations
// (объект, потом control block) — make_shared делает одну, поэтому предпочтительнее// (the object, then the control block) — make_shared does one, so it's preferred

Сам объект T не защищён mutex-ом через shared_ptr — потокобезопасен только счётчик ссылок. Конкурентное чтение/запись в сам T требует собственной синхронизации, как и для любого разделяемого состояния.The object T itself isn't protected by a mutex through shared_ptr — only the reference count is thread-safe. Concurrent reads/writes to T itself require their own synchronization, same as any other shared state.

Ожидаемый на интервью объём: control block с atomic-счётчиком, copy инкрементит, деструктор декрементит и удаляет объект при достижении нуля. Без weak_ptr и без единой аллокации make_shared — это уже отдельные усложнения, которые обычно не спрашивают сходу.The scope expected in an interview: a control block with an atomic counter, copy increments it, the destructor decrements it and deletes the object once it reaches zero. Without weak_ptr and without make_shared's single-allocation trick — those are separate complications that usually aren't asked upfront.

my_shared_ptr.hpp

#include <atomic>

template <class T>
class my_shared_ptr {
    T* ptr_ = nullptr;
    std::atomic<long>* count_ = nullptr;

    void release() {
        if (count_ && count_->fetch_sub(1, std::memory_order_acq_rel) == 1) {
            delete ptr_;
            delete count_;
        }
    }
public:
    my_shared_ptr() noexcept = default;

    explicit my_shared_ptr(T* p)
        : ptr_(p), count_(p ? new std::atomic<long>(1) : nullptr) {}

    // copy — инкремент счётчика// copy — increments the counter
    my_shared_ptr(const my_shared_ptr& other) noexcept
        : ptr_(other.ptr_), count_(other.count_) {
        if (count_) count_->fetch_add(1, std::memory_order_relaxed);
    }

    my_shared_ptr& operator=(const my_shared_ptr& other) noexcept {
        if (this != &other) {
            release();
            ptr_ = other.ptr_;
            count_ = other.count_;
            if (count_) count_->fetch_add(1, std::memory_order_relaxed);
        }
        return *this;
    }

    // move — без атомарной операции, просто забираем указатели// move — no atomic operation, we simply take over the pointers
    my_shared_ptr(my_shared_ptr&& other) noexcept
        : ptr_(other.ptr_), count_(other.count_) {
        other.ptr_ = nullptr;
        other.count_ = nullptr;
    }

    ~my_shared_ptr() { release(); }

    T& operator*()  const { return *ptr_; }
    T* operator->() const { return ptr_; }
    T* get()         const { return ptr_; }

    long use_count() const {
        return count_ ? count_->load(std::memory_order_relaxed) : 0;
    }
};

Типичные уточняющие вопросы после базовой реализации: почему инкремент можно делать с memory_order_relaxed (копирующий поток уже владеет валидным shared_ptr — никакой другой поток не может параллельно довести счётчик до нуля и удалить объект, пока жива хотя бы одна копия), а финальный декремент — с memory_order_acq_rel (нужен acquire, чтобы гарантированно увидеть все обращения к объекту из других потоков-«совладельцев» перед его удалением — тот же паттерн, что в atomic.html).Typical follow-up questions after the basic implementation: why the increment can use memory_order_relaxed (the copying thread already owns a valid shared_ptr — no other thread can concurrently drive the counter to zero and delete the object while at least one copy is alive), and why the final decrement needs memory_order_acq_rel (an acquire is needed to guarantee visibility of all accesses to the object made by other "co-owner" threads before deleting it — the same pattern as in atomic.html).

• cppreference — std::shared_ptr
• cppreference — std::enable_shared_from_this
• WG21 N2351 — shared_ptr additions to update Technical Report