На текущий момент мы с вами познакомились с основными
и наиболее полезными возможностями умных указателей,
которые приходится часто использовать на практике.
В этом видео мы поговорим о некоторых дополнительных возможностях,
которые на практике используются не так часто,
но если они нужны,
то лучше знать о том,
как их делать, иначе без них будет достаточно тяжело.
И цель этого видео не в том чтобы о них рассказывать подробно, а кратко показать,
что можно с их помощью делать для того
чтобы когда у вас на практике возникнет в них необходимость,
вы вспомнили, ага, что-то такое было,
что-то такое знаю, ничего не помню,
но сейчас почитаю и станет понятно.
Конкретно мы поговорим о двух вещах,
это о еще одном умном указатель weak_ptr и о пользовательском deleter,
который можно использовать shared_ptr.
Так, начнем с weak_ptr.
Пусть у нас есть следующий пример,
некоторый класс, который кеширует widget-ы,
у него есть функция GetWidget и передается имя и она возвращает widget с данным именем,
если у нее этот widget уже есть,
она возвращает готовый widget shared_ptr на него,
если же этого widget-а нет - она его создает.
И внутри себя она хранит map-ку,
строке соответствует shared_ptr на widget.
Это отлично работает, но есть одна небольшая проблема.
Даже если мы создали какой-то widget и в программе его уже больше не используем,
этот widget все равно будет существовать,
потому что на него сохраняется shared_ptr внутри этого объекта кеша,
то есть widget мы не используем,
но он все равно у нас висит,
как бы, и зачем возможно он отжирает некоторые ресурсы.
Нам бы хотелось сделать так,
что если в остальной программе мы перестали пользоваться этим widget-ом,
чтобы этот widget удалялся.
Как это можно сделать?
Первая мысль, которая приходит в голову,
почему бы нам не использовать shared_ptr::use_count().
Мы уже видели видео про многопоточность,
что существует use_count() и он вернет нам
текущее количество ссылок из shared_ptr на данный объект.
Если мы видим, что этот use_count() == 1 - это значит,
что только внутри нашего кеша хранится shared_ptr на этот объект,
а больше в программе нигде не используется,
и соответственно, мы можем его удалить.
Ну казалось бы да,
но есть некоторая проблема.
Мы же не знаем точный момент,
когда в остальной программе у нас уничтожится последний shared_ptr,
который указывает на этот widget,
то есть непонятно когда этот use_count() вызывать.
Мы можем подумать, ну ладно,
давайте заведем какой-нибудь фоновый поток
в котором будем по таймеру смотреть на use_count(),
хорошо, так в принципе можно сделать,
но тут возникает другая проблема,
как мы уже знаем use_count() в многопоточной
среде использовать очень не надёжно, потому что значение,
которое возвращает use_count() оно устаревает ровно в тот момент,
когда мы его получили,
ибо ровно в этот же самый момент из другого
потока кто-то может у нас запросить этот же самый widget,
и соответственно, счетчик ссылок у нас увеличится на одиночку.
Получается что, если нам нужен use_count(),
нам нужен фоновый поток, но если фоновый поток - мы не можем использовать use_count().
Есть другое решение, более подходящее в данном случае,
это как раз с использованием weak_ptr.
weak_ptr - это не владеющий умный указатель.
Казалось бы, он вроде бы умный,
но почему он тогда не владеющий?
Чем он лучше обычного сырого указателя?
Дело в том, что из weak_ptr можно корректно создать shared_ptr,
который уже будет владеющим.
Как мы знаем, из сырого указателя
создавать shared_ptr - это гиблое дело.
Это вообще считается низкоуровневым управлением динамической памятью,
потому что каждый раз,
когда мы создаем shared_ptr из сырого
указателя у нас для этого объекта заводится свой контрольный блок,
и созданный таким образом shared_ptr оказываются не связанными друг с другом,
и они скорее всего приведут к двойному удалению объекта.
А от из weak_ptr можно абсолютно корректно создавать shared_ptr
и все эти shared_ptr будут иметь один и тот же контрольный блок.
Давайте посмотрим, как у нас изменится код с использованием weak_ptr.
Смотрите, теперь у нас в map-ке мы храним уже не shared_ptr,
а weak_ptr и посмотрим на реализацию функцию GetWidget.
Первым делом мы обращаемся к элементу map-ки с данным name,
это будет weak_ptr и мы вызываем у него метод lock.
Метод lock у weak_ptr как раз создает shared_ptr, для того объекта,
на который указывает этот weak_ptr,
если такой объект есть, соответственно,
если такой объект есть,
то мы получаем у него него shared_ptr и возвращаем и все хорошо.
А вот если его, если этого объекта нет, что происходит?
Объекта может не быть по двум причинам: либо этот объект еще не был создан вообще,
в принципе мы только создали кэш и в кэше widget-а с этим именем нет,
либо и это самое главное,
этот объект когда-то был создан,
но с тех пор им перестали пользоваться,
то есть мы когда-то отдали на него shared_ptr,
но потом этот shared_ptr и все его копии
были уничтожены и объектом больше никто не пользуется,
счетчик ссылок упал до нуля,
тогда этот объект будет удален и weak_ptr сможет понять,
что объект был удален.
Соответственно, в обоих этих случаях метод lock вернет нам пустой shared_ptr,
это будет обозначать, что объекта у нас нет, по той или иной причине.
В этом случае мы зайдем в условия в if,
и поскольку у нас объекта нет,
но соответственно, его нужно создать,
поэтому мы точно таким же образом вызываем функцию
make_shared для widget с данным именем,
она возвращает shared_ptr, этот shared_ptr мы
неявно конвертируем в weak_ptr и складываем его в map-ку.
После этого мы этот shared_ptr возвращаем.
Вот таким не сложным исправление мы смогли добиться ровно того поведения этой программы,
которая нам нужна, за счет использования еще
одного специфического умного показателя weak_ptr.
А в следующем видео мы с вами поговорим о пользовательских deleter-ах.
