std::unique_ptr изнутриinternals

В типичном случае (без пользовательского deleter, или с deleter без состояния, например обычной функцией) std::unique_ptr<T> внутри — это буквально один сырой указатель T*, и ничего больше. Никакого счётчика ссылок, никакого control block — вся модель владения существует только на уровне типовой системы компилятора, а не в рантайме.In the typical case (no custom deleter, or a stateless one — an ordinary function, say), std::unique_ptr<T> internally is literally one raw T* pointer and nothing else. No reference count, no control block — the entire ownership model exists only at the compiler's type-system level, not at runtime.

static_assert(sizeof(std::unique_ptr<int>) == sizeof(int*));  // проходит на всех мейнстрим-реализациях// holds on every mainstream implementation

Если задан deleter с состоянием (например, лямбда, захватывающая переменные), unique_ptr использует compressed_pair-подобную оптимизацию: если deleter — пустой класс без состояния (stateless functor), Empty Base Optimization позволяет не выделять под него отдельную память вовсе — итоговый размер остаётся равен размеру одного указателя даже с кастомным (но пустым) deleter-типом.If a stateful deleter is given (say, a lambda capturing variables), unique_ptr uses a compressed_pair-like optimization: if the deleter is an empty, stateless class (a stateless functor), the Empty Base Optimization avoids allocating any storage for it at all — the final size stays equal to one pointer's size even with a custom (but empty) deleter type.

Copy-конструктор и copy-присваивание объявлены как = delete — попытка скопировать unique_ptr не компилируется, а не молча создаёт второго владельца того же ресурса. Move-конструктор просто копирует значение сырого указателя из источника в приёмник и обнуляет указатель в источнике — сам ресурс никогда физически не перемещается, перемещается только владение им.The copy constructor and copy assignment operator are declared = delete — attempting to copy a unique_ptr fails to compile, rather than silently creating a second owner of the same resource. The move constructor simply copies the raw pointer's value from the source into the destination and nulls out the source's pointer — the resource itself never physically moves, only ownership of it does.

template<typename T>
class MyUniquePtr {
    T* ptr = nullptr;
public:
    explicit MyUniquePtr(T* p = nullptr) : ptr(p) {}

    MyUniquePtr(const MyUniquePtr&) = delete;               // нельзя копировать// no copying
    MyUniquePtr& operator=(const MyUniquePtr&) = delete;

    MyUniquePtr(MyUniquePtr&& other) noexcept : ptr(other.ptr) {
        other.ptr = nullptr;                          // источник больше не владеет ничем// the source no longer owns anything
    }
    MyUniquePtr& operator=(MyUniquePtr&& other) noexcept {
        if (this != &other) {
            delete ptr;                               // освободить то, чем владели раньше// release whatever was owned before
            ptr = other.ptr;
            other.ptr = nullptr;
        }
        return *this;
    }

    ~MyUniquePtr() { delete ptr; }               // delete nullptr — безопасен, ничего не делает// delete nullptr is safe, a no-op

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

    T* release() { T* tmp = ptr; ptr = nullptr; return tmp; }  // отдать владение, не удаляя// give up ownership without deleting
    void reset(T* p = nullptr) { delete ptr; ptr = p; }         // удалить старое, взять новое// delete the old, take the new
};

Это и есть тот самый «реализуй unique_ptr сам» — примерно 25 строк, покрывающих RAII, запрет копирования, move-семантику и базовый интерфейс. Именно компактность этой реализации — причина, по которой она так популярна как вопрос: она проверяет одновременно понимание Rule of 5, move-семантики и RAII в одном небольшом куске кода.This is exactly the "implement unique_ptr yourself" ask — roughly 25 lines covering RAII, the ban on copying, move semantics, and the basic interface. That compactness is exactly why it's such a popular question: it checks understanding of the Rule of 5, move semantics, and RAII all in one small piece of code.

В отличие от shared_ptr, где deleter — деталь рантайма (два shared_ptr<T> с разными deleter-ами — один и тот же тип), у unique_ptr тип deleter-а — часть самого типа std::unique_ptr<T, Deleter>. Это прямое следствие «нулевых накладных расходов»: раз в рантайме не хранится указатель на функцию-удалитель, единственный способ узнать, как удалять объект, — закодировать это в типе на этапе компиляции.Unlike shared_ptr, where the deleter is a runtime detail (two shared_ptr<T> instances with different deleters are the same type), unique_ptr's deleter type is part of the type itself: std::unique_ptr<T, Deleter>. This is a direct consequence of "zero overhead": since no function pointer to a deleter is stored at runtime, the only way to know how to delete the object is to encode it in the type at compile time.

auto fileDeleter = [](FILE* f) { if (f) fclose(f); };
std::unique_ptr<FILE, decltype(fileDeleter)> file(fopen("data.txt", "r"), fileDeleter);
// тип включает Deleter — нельзя присвоить unique_ptr сюда// the type includes Deleter — a unique_ptr can't be assigned here

• cppreference — std::unique_ptr