Как може да се доведе до изтичане на памет при…

Това е трудно, но в определени сценарии е възможно:

Циклични зависимости (съвместно притежание обход на single-ownership): Ако два unique_ptr притежават обекти, които се позовават един на друг, и нито един от тях не бъде унищожен първи, паметта няма да бъде освободена. Това нарушава философията на unique_ptr като единствен собственик. В такива случаи по-добре е да се използва shared_ptr с weak_ptr.

#include <memory>

struct A;
struct B;

struct A {
    std::unique_ptr<B> ptr_b;
    A() {}
    ~A() { /* деструктор A */ }
};

struct B {
    std::unique_ptr<A> ptr_a; // Това зависи циклично от A
    B() {}
    ~B() { /* деструктор B */ }
};

int main() {
    auto a = std::make_unique<A>();
    auto b = std::make_unique<B>();
    // Настройване на взаимни препратки
    // Това ще доведе до изтичане, ако собственикът a или b не унищожи първи своя `unique_ptr`,
    // което е невъзможно в този случай поради цикличната зависимост
    a->ptr_b = std::move(b);
    // След изход от main, `a` ще бъде унищожен, но неговият деструктор ще се опита да освободи ptr_b. Ако ptr_b сочи към B,
    // който съдържа `unique_ptr<A>`, който сочи към оригиналния A,
    // ще се получи циклична зависимост, водеща до изтичане, ако не се управлява внимателно.
    // В този пример, само `a` остава в scope и неговият деструктор ще се извика.
    // Изтичане ще се случи, ако B притежава A, а A притежава B.
    // Тук `b` е преместен в `a->ptr_b`. `unique_ptr<B> b` в main е празен.
    // След изход от main, `a` ще бъде унищожен, деструкторът ще се извика.
    // Вика се деструкторът.
    // Проблемът с цикличното притежание възниква, когато обектите не могат да се унищожат взаимно
    // заради това, че всеки притежава друг.
    // Правилен пример за циклична зависимост:
    // struct A { std::unique_ptr<B> b; };
    // struct B { A* a_raw_ptr; }; // B знае за A, но не го притежава

    // При `unique_ptr` цикличното *притежание* е изключително необичайно и трудно се създава директно
    // без явни грешки в дизайна. Обикновената циклична препратка не води до изтичане сама по себе си
    // с `unique_ptr`, ако няма цикличо притежание.

    // **Истински сценарий на изтичане с `unique_ptr` в контекста на цикли:**
    // Това не е заради самия `unique_ptr`, а заради логиката на притежание.
    // Например, ако имате структура, която *съхранява* `unique_ptr` към друга структура,
    // която от своя страна *съхранява* `unique_ptr` към първата структура, и създавате такива обекти
    // с `new` и ги присвоявате на `unique_ptr`:
    // auto obj1 = std::make_unique<A>();
    // auto obj2 = std::make_unique<B>();
    // obj1->ptr_b = std::move(obj2); // obj1 сега притежава obj2
    // obj1->ptr_b->ptr_a = std::move(obj1); // <- ТУК ПРОБЛЕМЪТ: obj2 се опитва да притежава obj1,
    //                                      // който вече притежава obj2.
    //                                      // Това ще доведе до грешка по време на изпълнение или неинициализиран `unique_ptr`,
    //                                      // а не до циклично изтичане като при `shared_ptr`.

    // **Най-вероятният сценарий на изтичане с `unique_ptr` в зависимостите:**
    // Ако използвате суров указател вътре в обект, към който сочи `unique_ptr`,
    // и този суров указател сочи към обект, който притежава друг `unique_ptr`, и забравите
    // да освободите суровия указател, когато вторият `unique_ptr` бъде унищожен *по-рано*.
    // Но това не е изтичане на `unique_ptr`, а изтичане на суров указател или неправилна употреба на паметта.

    // Фокусирайте се върху това, как `unique_ptr` може да допринесе за изтичане,
    // а не върху грешки в дизайна извън него.
    // Най-прякият начин е чрез изключение.
}

Изключение при създаване на обект: Ако при създаване на обект, който unique_ptr ще притежава, или по време на конструктора на този обект възникне изключение след алокацията на памет (new T()), но преди присвояването на тази памет към unique_ptr.

#include <memory>

class Resource {
public:
    Resource() {
        // Ако тук възникне изключение...
        throw std::runtime_error("Грешка в конструктора Resource");
    }
    ~Resource() {
        // този деструктор няма да бъде извикан, ако възникне изключение в конструктора
    }
};

int main() {
    Resource* res = nullptr;
    try {
        res = new Resource(); // паметта е алокирана
        // ... но възниква изключение преди `unique_ptr` да вземе владение
        // std::unique_ptr<Resource> unique_resource(res); // <- до тук кодът няма да достигне
        std::cout << "Тази линия няма да бъде изпълнена" << std::endl;
    } catch (const std::exception& e) {
        std::cerr << "Изключение: " << e.what() << std::endl;
        // `res` съдържа указател към алокираната памет, но никога не е бил присвоен
        // `unique_ptr`, и не е бил явно освободен. Утечка.
        // Правилно е: delete res; // в блока catch
    }
    // Утечка на памет, ако delete res; не е извикан в catch блока.

    // **Как да избегнем утечка с `unique_ptr` в този случай:**
    // Използвайте `std::make_unique`
    try {
        std::unique_ptr<Resource> безопасен_resource = std::make_unique<Resource>(); // RAII
        // Ако в конструктора на Resource възникне изключение, `make_unique`
        // правилно ще се погрижи за освобождаването на алокираната памет.
    } catch (const std::exception& e) {
        std::cerr << "Обработено изключение от `make_unique`: " << e.what() << std::endl;
        // Няма изтичане
    }
    return 0;
}

Некоректен deleter: Ако unique_ptr е конфигуриран с потребителски deleter, който не изпълнява своята функция.

#include <memory>
#include <iostream>

struct MyData {
    int value;
    MyData(int v) : value(v) { std::cout << "MyData(" << value << ") създаден" << std::endl; }
    ~MyData() { std::cout << "MyData(" << value << ") унищожен" << std::endl; }
};

// Потребителски deleter, който *не* освобождава паметта
struct NoOpDeleter {
    void operator()(MyData* ptr) const {
        std::cout << "NoOpDeleter е извикан за " << ptr->value << ", но не изтрива!" << std::endl;
        // delete ptr; // <- Забравили са да uncomment-нат delete или умишлено не изтриват
    }
};

int main() {
    // Създаване на `unique_ptr` с потребителски deleter
    std::unique_ptr<MyData, NoOpDeleter> data_ptr(new MyData(10));
    // При изход от scope, ще бъде извикан `NoOpDeleter`.
    // Тъй като `NoOpDeleter` не извиква delete, паметта, алокирана чрез `new MyData(10)`,
    // няма да бъде освободена. Утечка.
    return 0;
    // ~unique_ptr() ще се извика, извиква `NoOpDeleter::operator()`, но паметта не се изтрива.
}

Виклик .release() без последващ delete: Методът release() предава владението на суров указател. Ако този указател не бъде явно изтрит (или предаден на друг умствен указател), ще настъпи изтичане.

#include <memory>
#include <iostream>

struct LeakyResource {
    LeakyResource() { std::cout << "LeakyResource създаден" << std::endl; }
    ~LeakyResource() { std::cout << "LeakyResource унищожен" << std::endl; }
};

int main() {
    std::unique_ptr<LeakyResource> ptr = std::make_unique<LeakyResource>();

    LeakyResource* raw_ptr = ptr.release(); // `ptr` сега е празен (nullptr)
    // Владеенето е преминало към `raw_ptr`.
    // Паметта, към която сочи `raw_ptr`, няма да бъде автоматично освободена
    // при изход от `main`.

    // ... работа с `raw_ptr` ...

    // Забравили са да изтрият!
    // delete raw_ptr; // <- Утечка, ако този ред липсва

    std::cout << "ptr е " << (ptr ? "не е null" : "null") << std::endl; // Ще изведе "ptr е null"

    return 0; // raw_ptr все още сочи към алокираната памет, но тя не е освободена
}

Във всички останали стандартни сценарии unique_ptr, базиран на RAII, правилно управлява паметта, освобождавайки я при изход от scope.

Как може да се доведе до изтичане на памет при използване на unique_ptr?