Широко распространенное использование shared_ptr почти неизбежно приведет к нежелательному и невидимому заполнению памяти.
Циклические ссылки являются хорошо известной причиной, и некоторые из них могут быть косвенными и их трудно обнаружить, особенно в сложном коде, над которым работает более одного программиста; программист может решить, что один объект нуждается в ссылке на другой в качестве быстрого решения, и у него нет времени, чтобы проверить весь код, чтобы увидеть, закрывает ли он цикл. Эта опасность чрезвычайно недооценена.
Менее понятна проблема невыпущенных ссылок. Если объект является общим для многих shared_ptrs, то он не будет уничтожен, пока каждый из них не обнулится или не выйдет из области видимости. Очень легко пропустить одну из этих ссылок и в конечном итоге увидеть скрытые в памяти объекты, о которых вы думали, что покончили с ними.
Хотя, строго говоря, это не утечки памяти (все они будут устранены до выхода из программы), они так же вредны и труднее обнаружить.
Эти проблемы являются следствием целесообразных ложных заявлений:
1. Объявление того, кем вы действительно хотите быть единоличным владельцем, как shared_ptr. scoped_ptr будет правильным, но тогда любая другая ссылка на этот объект должна быть необработанным указателем, который можно оставить висящим.
2. Объявление того, что вы действительно хотите использовать в качестве пассивной наблюдательной ссылки, как shared_ptr. Слабый_портр был бы верным, но тогда у вас есть проблемы с преобразованием его в share_ptr каждый раз, когда вы хотите его использовать.
Я подозреваю, что ваш проект - прекрасный пример того рода неприятностей, с которыми эта практика может вас завести.
Если у вас есть приложение с интенсивным использованием памяти, вам действительно нужно одно владение, чтобы ваш проект мог явно контролировать время жизни объекта.
с одним владельцем opObject = NULL; обязательно удалит объект и сделает это сейчас.
с общим владением spObject = NULL; ........ кто знает? ......