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

Это сложно, но возможно при определенных сценариях:

1. Циклические зависимости (совместное владение в обход 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 unique_ptr<A> a будет уничтожен, но его деструктор A
       // попытается уничтожить ptr_b. Однако, если ptr_b владел объектом B,
       // а объект B содержит unique_ptr<A>, который владел исходным объектом A,
       // возникнет циклическая зависимость, leading to a leak if not carefully managed.
       // В данном конкретном упрощенном примере с make_unique только a останется в scope
       // и его деструктор вызовется. Утечка произойдет, если B владеет A, а A владеет B.
       // Здесь b moved в a->ptr_b. unique_ptr<B> b в main теперь пуст.
       // При выходе из main, a уничтожится. Деструктор A вызовется.
       // Деструктор unique_ptr<B> ptr_b вызовется.
       // Деструктор B вызовется.
       // Деструктор unique_ptr<A> ptr_a в B вызовется.
       // Проблема с циклом владений возникает, когда объекты не могут уничтожить друг друга
       // из-за того, что каждый владеет другим.
       // Правильный пример циклической зависимости:
       // 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 может способствовать утечке,
       // а не на ошибках дизайна вне его.
       // Самый прямой способ - это исключение.
   }
   

2. Исключения во время создания объекта: Если при создании объекта, которым 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> safe_resource = std::make_unique<Resource>(); // RAII
           // Если в конструкторе Resource происходит исключение, make_unique
           // корректно обработает освобождение выделенной памяти.
       } catch (const std::exception& e) {
           std::cerr << "Исключение обработано make_unique: " << e.what() << std::endl;
           // Утечки нет
       }
       return 0;
   }
   

3. Некорректный deleter: Если unique_ptr сконфигурирован с пользовательским deletere, который не выполняет свою функцию.

   #include <memory>
   #include <iostream>
   
   struct MyData {
       int value;
       MyData(int v) : value(v) { std::cout << "MyData(" << value << ") created" << std::endl; }
       ~MyData() { std::cout << "MyData(" << value << ") destroyed" << std::endl; }
   };
   
   // Пользовательский deleter, который *не* удаляет память
   struct NoOpDeleter {
       void operator()(MyData* ptr) const {
           std::cout << "NoOpDeleter called for " << ptr->value << ", but not deleting!" << std::endl;
           // delete ptr; // <- Забыли раскомментировать delete или намеренно не удаляем
       }
   };
   
   int main() {
       // Создаем unique_ptr с пользовательским deletere
       std::unique_ptr<MyData, NoOpDeleter> data_ptr(new MyData(10));
       // При выходе из области видимости data_ptr, будет вызван NoOpDeleter.
       // Поскольку NoOpDeleter не вызывает delete, память, выделенная через new MyData(10),
       // не будет освобождена. Утечка памяти.
       return 0;
       // ~unique_ptr() вызывается, вызывает NoOpDeleter::operator()(data_ptr.get()),
       // но память не удаляется.
   }
   

4. Вызов .release() без последующего delete: Метод release() отдает владение сырому указателю. Если этот сырой указатель не будет затем явно удален (или передан другому умному указателю), произойдет утечка.

   #include <memory>
   #include <iostream>
   
   struct LeakyResource {
       LeakyResource() { std::cout << "LeakyResource created" << std::endl; }
       ~LeakyResource() { std::cout << "LeakyResource destroyed" << 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 is " << (ptr ? "not null" : "null") << std::endl; // Выведет "ptr is null"
   
       return 0; // raw_ptr все еще указывает на выделенную память, но она не удалена
   }
   

Во всех остальных стандартных сценариях unique_ptr, основанный на RAII (Resource Acquisition Is Initialization), корректно управляет памятью, освобождая ее при выходе из области видимости.