>> Вообще нигде не было бы, даже в ассемблере.
> Как это? В ассемблере же ни смарт-пойнтеров, ни сборщика мусора нет. Наверное
> какая-то глубокая философия была.Потому что до тех пор, пока у нас есть указатель вписывающийся в идею uniq_ptr, отследить время жизни объекта не просто, а крайне просто. Я не знаю кем надо быть, чтобы забыть его удалить.
>> Иногда хочется иметь ссылку на объект в разных стековых фреймах, а иногда ещё и в структурке хранить её удобно.
> "В структурке"? Сишника в вас ощущаю я.
Пфеу.
> В С++ есть решение из коробки, std::shared_ptr. Помогает в большинстве случаев.
Угу. Да, подсчёт ссылок решает большинство таких проблем, я о том и говорю. Но не все. Я когда-то читал у Кнута, что подсчётом ссылок можно решать на системном уровне даже работу с циклическими объектами, но с тех пор так и не собрался походить по ссылкам и выяснить -- не врал ли он.
>> А ещё иногда объект прямо или косвенно ссылается сам на себя, тогда даже ref_count не всегда спасает.
> В этом случае и сборщик мусора не всегда спасает.
В этом случае спасает. Даже консервативный сборщик мусора одетый на C++ сможет эту проблему вычленить и освободить память. Правда он консервативный -- он не имеет информации о типах переменных, и поэтому если какой-нибудь буфер, куда был прочитан файл, содержит значение похожее на указатель в потерянный объект, то он сохранит этот объект на всякий случай.
> Вот вам хорошая презенташка про утечки памяти в Java:
> http://www.slideshare.net/RafaelWinterhalter/a-topology-of-m...
Ой, ну естественно. Если ты подключаешь к программе со сборкой мусора библиотеки без сборки мусора, то их объекты сборщик мусора не может тупо удалять, потому что он не может проверить unsafe код на предмет владения указателями. Если ты начинаешь использовать unsafe код, то половина гарантий, которые даёт язык просто отваливаются, и там всё упирается в то, способен ли ты управлять памятью вручную.
Это проблемы не сборщика мусора, как такового -- это проблемы вылезающие из-за неиспользования сборщика мусора кодом.
