std::unique_ptr

std::unique_ptr<T> — RAII-обёртка над указателем, которая владеет объектом единолично: при уничтожении unique_ptr (выход из скоупа, исключение, явный reset) автоматически вызывается delete (или пользовательский deleter) над управляемым объектом. Copy-конструктор и copy-присваивание явно удалены (= delete) — существует только move-конструктор и move-присваивание.std::unique_ptr<T> is a RAII wrapper around a pointer that owns its object exclusively: when the unique_ptr is destroyed (scope exit, an exception, an explicit reset), delete (or a custom deleter) is automatically invoked on the managed object. The copy constructor and copy assignment operator are explicitly deleted (= delete) — only a move constructor and move assignment operator exist.

Widget* w = new Widget();
// ... использование ...// ... usage ...
// нужно не забыть delete w на каждом пути выхода,// you must remember delete w on every exit path,
// включая исключения — источник утечек// including exceptions — a source of leaks

auto w = std::make_unique<Widget>();
// использование ...// usage ...
// delete вызывается автоматически при выходе из скоупа,// delete is called automatically on scope exit,
// в том числе при исключении// including when an exception is thrown

unique_ptr закрывает главный источник утечек и double-free в до-C++11 коде:unique_ptr closes off the main source of leaks and double-frees in pre-C++11 code:

unique_ptr — тонкая обёртка практически без overhead: хранит указатель на объект (и, если deleter стейтфул, сам deleter — обычно оптимизируется до нулевого дополнительного размера через empty base optimization при stateless deleter). Copy-конструктор и copy-присваивание объявлены как = delete, поэтому компилятор отклоняет любую попытку копирования на этапе компиляции — это статическая, а не рантайм-гарантия.unique_ptr is a thin wrapper with practically no overhead: it stores a pointer to the object (and, if the deleter is stateful, the deleter itself — usually optimized down to zero extra size via empty base optimization for a stateless deleter). The copy constructor and copy assignment operator are declared = delete, so the compiler rejects any attempt to copy at compile time — a static guarantee, not a runtime one.

std::unique_ptr<Widget> a = std::make_unique<Widget>();
// std::unique_ptr<Widget> b = a;       // ошибка компиляции — copy-конструктор = delete// std::unique_ptr<Widget> b = a;       // compile error — copy constructor = delete
std::unique_ptr<Widget> b = std::move(a); // ок — move-конструктор передаёт владение,// ok — the move constructor transfers ownership,
                                            // a становится nullptr// a becomes nullptr

// кастомный deleter — часто для не-new/delete ресурсов:// a custom deleter — often used for non-new/delete resources:
auto file_closer = [](FILE* f) { if (f) fclose(f); };
std::unique_ptr<FILE, decltype(file_closer)> fp(fopen("x", "r"), file_closer);

// массивы — частичная специализация unique_ptr<T[]>:// arrays — the unique_ptr<T[]> partial specialization:
std::unique_ptr<int[]> arr(new int[10]);  // деструктор вызовет delete[], не delete// the destructor calls delete[], not delete

Возврат unique_ptr из функции по значению — стандартный паттерн: компилятор применяет move (или RVO), а не копирование, потому что copy-конструктор недоступен, а move — доступен и дёшев (передача одного указателя).Returning a unique_ptr from a function by value is a standard pattern: the compiler applies move (or RVO) rather than copy, because the copy constructor is unavailable while move is available and cheap (transferring a single pointer).

Минимальный skeleton без deleter-параметра и без специализации под массивы — этого достаточно, чтобы показать понимание RAII + move-only семантики за отведённое время.A minimal skeleton with no deleter parameter and no array specialization — that's enough to demonstrate understanding of RAII + move-only semantics within the allotted time.

my_unique_ptr.hpp

template <class T>
class my_unique_ptr {
    T* ptr_ = nullptr;
public:
    my_unique_ptr() noexcept = default;
    explicit my_unique_ptr(T* p) noexcept : ptr_(p) {}

    ~my_unique_ptr() { delete ptr_; }

    // copy запрещён — единоличное владение// copy is disallowed — sole ownership
    my_unique_ptr(const my_unique_ptr&)            = delete;
    my_unique_ptr& operator=(const my_unique_ptr&) = delete;

    // move — передача владения, источник обнуляется// move — ownership transfer, the source is nulled out
    my_unique_ptr(my_unique_ptr&& other) noexcept
        : ptr_(other.ptr_) {
        other.ptr_ = nullptr;
    }

    my_unique_ptr& operator=(my_unique_ptr&& other) noexcept {
        if (this != &other) {
            delete ptr_;
            ptr_ = other.ptr_;
            other.ptr_ = nullptr;
        }
        return *this;
    }

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

    T* release() noexcept {
        T* tmp = ptr_;
        ptr_ = nullptr;
        return tmp;
    }

    void reset(T* p = nullptr) noexcept {
        delete ptr_;
        ptr_ = p;
    }

    explicit operator bool() const { return ptr_ != nullptr; }
};

Что обычно проверяют дополнительным вопросом: почему operator=(my_unique_ptr&&) нужна проверка this != &other (self-move-assignment — иначе delete ptr_ удалит объект до того, как ptr_ = other.ptr_ его переприсвоит, хотя тут ptr_ == other.ptr_ и баг не проявится физически, но привычка проверять обязательна), и куда добавить кастомный deleter (второй шаблонный параметр + хранение его как поля, обычно через [[no_unique_address]] в более поздних стандартах или EBO-приём в C++11).What's usually probed with a follow-up question: why operator=(my_unique_ptr&&) needs the this != &other check (self-move-assignment — otherwise delete ptr_ would destroy the object before ptr_ = other.ptr_ reassigns it, though here ptr_ == other.ptr_ so the bug wouldn't physically manifest, but the habit of checking is still mandatory), and where a custom deleter would go (a second template parameter plus storing it as a field, typically via [[no_unique_address]] in later standards, or the EBO trick in C++11).

• cppreference — std::unique_ptr
• WG21 N2955 — Smart Pointers (unique_ptr wording)