>> Потому что до тех пор, пока у нас есть указатель вписывающийся в идею uniq_ptr, отследить время жизни объекта не просто, а крайне просто. Я не знаю кем надо быть, чтобы забыть его удалить.
> Не всегда просто. Легко забыть сделать delete перед return в середине функции.
> Особенно если указателей несколько, return-ов тоже несколько, и надо перед разными
> return надо делать разный набор delete. Также вместо преждевременного return бывает
> исключение, да ещё в какой-нибудь вложенной функции.Вот нефиг писать исключительно на C++. Попробуй пописать на C или asm годик, тебе в кровь въестся идея, что return из середины функции -- это плохо, и прежде чем так делать, нужно три раза подумать. ;)
Это реально выходит на уровень условного рефлекса, который срабатывает всегда, при виде return, за которым тело функции продолжается. Даже если писать приходится на питоне -- всё равно срабатывает. Так и хочется вместо return написать goto finish.
Или, если на C/asm аллергия, то вместо них можно попробовать какую-нибудь функциональщину, в которой вообще использование return -- признак дурного тона, а для cleanup кода, если он нужен, есть какой-нибудь особый костыль, позволяющий обходиться без return и без создания временной переменной для хранения результата вычислений, пока выполняется этот самый cleanup код. Что-нибудь типа unwind-protect в common lisp'е.
>> Да, подсчёт ссылок решает большинство таких проблем, я о том и говорю. Но не все.
> Так и GC не все. Да, теоретически GC может освободить больше памяти,
> чем RAII. А практически - оба подхода работают очень хорошо. А
> RAII может ещё и другие ресурсы автоматически освобождать, например закрывать файлы,
> сетевые соединения, БД-соединения и т.д.
Я в последний раз сталкивался с жабой лет пятнадцать назад, но даже тогда она умела закрывать файловые дескрипторы, когда умирали объекты, владеющие ими. Там было что-то типа метода finalize -- деструктор, который вызывался непосредственно перед освобождением памяти. Это было дерьмово, потому что пока сборщик мусора не выяснит, что объект умер, он не вызовет finalize, а finalize не вызовет close(2) и файловый дескриптор будет оставаться открытым, что неудачно, если много файловых дескрипторов открывается и закрывается. Поэтому всё равно, стоило закрывать файлы прежде чем терять ссылки на них. Но это было даже тогда. Ну, чтобы это работало, конечно же, надо избегать работать с файловым дескриптором напрямую и работать с ним исключительно через посредство специально созданного объекта со специально заточенным finalize.
>> В этом случае спасает.
> Циклические ссылки циклическим ссылкам рознь. Не всегда GC может их правильно раскрутить.
Если циклическая ссылка недоступна из корневого указателя, то gc её даже не найдёт, потому что он ищет не объекты, которые нужно удалять, а объекты, которые нужно сохранять. Может речь про вызов деструкторов циклического объекта? Там, вероятно, могут возникать проблемы -- если у нас есть цикл из однотипных объектов, то чей деструктор вызывать первым? М-м-м... Я не думал об этом. Может просто вызвать их в рандомном порядке? Какая собственно разница.
>> unsafe код
> Посмотрите презентацию повнимательнее, дальше 7-й страницы. Так не только unsafe код.
Я не умею смотреть презентации, я их не понимаю -- какие-то случайным образом раскиданные по слайду непонятные схемки и буковки... Можно мне сам доклад текстом, а не только картинки из него?
