Я писал на C++ на умных указателях и моя память потекла. Пробуем починить.

Telegram: t.me/dev_pushkin
Leetcode: leetcode.com/idfumg
GitHub: github.com/idfumg
Cpp (with an issue): gist.github.com/idfumg/644ddf...
Cpp (ok): gist.github.com/idfumg/46aab1...
Memory Leaks.
Сегодня попробуем разобрать причину, почему память потекла в нашем предыдущем видео про Double Linked List, хоть мы и использовали умные указатели, которые должны были помочь нам избежать этого изначально. Нарисуем схематически, что произошло. Подумаем, как починить данную проблему и проверить, что утечек больше нет. Также рассмотрим еще один момент в первой нашей реализации и какие еще подводные камни могут быть, которые приведут к падению нашей программы в некоторых случаях. Не забываем использовать Rule of 5 и определять copy constructor, move constructor, copy assign operator, move assign operator, destructor. Либо, если у нас нет необходимости каким-то образом контролировать копии и мувы, отдаем приоритет Rule of 0 - оставляем дефолтные функции, сгенерированные компилятором.
#c++ #python #go #golang #memory_leaks #programming #data_structures #algorithms #computerscience

[@Fedor_Dokuchaev_Color]

Спасибо, хороший разбор и хороший канал. Вопрос: зачем копировать всю ноду с пойнтером в память для независимых операций, если можно записать только её значение в переменную? Проблема возникает именно с тем, что shared pointer остаётся висеть. Если лист ещё существует, можно после всех операций вернуться в эту ноду и вписать новое значение. Если лист мы уже убрали, значение по-прежнему доступно.

[@dev_pushkin]

Привет! Все очень сильно зависит от проблемы. В целом, чаще так вообще не пишут лист, проще использовать чистые указатели и скрывать работу с ними в реализации листа. Так как shared pointer это не zero cost abstraction и он тяжелый. Если многопоточка присутствует, то еще тяжелей. Но, иногда может понадобится "помнить" о данных в не зависимости от того, удалили или нет из листа. Копировать полностью только данные, имея shared pointer опасно. Так как у тебя может сработать reference counter == 0 & memory deallocation. В программе останется ссылка на не валидные данные. Копировать по значению же все - ну как бы можно, но не желательно, особенно повсеместно (за исключением некоторых оптимизаций компилятора, но здесь не про них)

[@Fedor_Dokuchaev_Color]

@@dev_pushkin Спасибо за ответ! "Копировать полностью только данные, имея shared pointer опасно. В программе останется ссылка на не валидные данные." Это про копирование через pass by reference? В целом CPP Core Guidelines предлагают использовать shared pointers только в случае, если нужно делиться владением (ownership), что логично.

[@dev_pushkin]

Я бы сказал pass a shared pointer value by reference. После этого, мы можем очистить память и у нас появляется UB. Передавать by reference сам pointer вполне норм, чтобы не увеличивать счетчик ссылок, что не самая дешевая операция (в зависимости от системы). Либо by value, если делим ownership. Я придерживаюсь мнения, что guidelines - это хорошо, но не вещь, которой слепо надо следовать. Если мы явно видим отличное место применить, будет довольно странно это не делать, потому что где-то написали, что это не по правилам (и делать потом громоздкий workaround вместо).

[@euuhgzz2791]

Проще юзать обычный указатель в любом случае Умные указатели это нагромождение, и рассадник ошибок при проектировании

[@dev_pushkin]

Верно. Я об этом упомянул в видео. Как вариант еще предложил unique ownership. Идея была в том, чтобы показать, что иногда такое все же бывает. Есть задачи, где не обойтись raw или unique pointers и нужно именно shared ownership. Не всегда они имеют циклические зависимости и тогда ок, но тоже бывает иногда. Также, кто переписывает с других языков с GC поведение может быть странным. Хотя и там такая проблема может быть не смотря на GC. Енивей, современные анализаторы хорошо помогают в отлове множества ошибок. В современных плюсах наоборот считается bad practice манипулировать raw pointers. Это часто приводило к проблемам в прошлом. Smart pointers и минимизация или исключение явного выделения памяти через new и malloc. Использование фабрик или make_unique, make_shared. This is the way.

[@Fedor_Dokuchaev_Color]

А чем unique pointer нагромождение? Он очень простой и избавляет от целого ряда случаев утечек памяти.