Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, lpd, Вы писали:

lpd>>Во-вторых, RAII это не серебрянная пуля. Полно случаев когда он не описывает сложное владение объектом.

CK>это какие же?

Самое простое это неудобные случаи когда время жизни объекта не совпадает со временем жизни переменной.
И например может быть два объекта со счетчиками ссылок, которые нужно удалять вместе, или с более сложной логикой. Я понимаю, что можно исхитриться, но это же неудобно.
Вообще идея связывать время жизни переменной и какие-то операции по освобождению ресурсов довольно сомнительная. Время жизни переменной — это исключительно синтаксическая вещь, а освобождение ресурсов — императивная операция. И писать обертки над функциями только чтобы создать временную переменную, рассчитывая что где-то компилятор ее удалит, это удалять зубы через нос.

lpd>>Может это и ясно, но синтаксис у умных указателей очень громоздкий. И тут начнутся всякие auto, с которыми уже вообще ничего в коде не видно.

CK>Это чем же он громоздкий? Сишные st1->st2.fld3->st4 это значит не громоздко совсем, да?
Ну все эти unique_ptr<Type> по мне очень длинны если их писать по любому поводу, Type * всяко короче.

CK>с помощью ASan довольно тривиально, но вообще это не приходится делать, если правильно проектировать архитектуру, то бишь делать так, чтобы граф зависимостей объектов был ацикличным и направленным (это также неплохо помогает от дедлоков), то что сишечка позволяет иметь кучу циклических ссылок между объектами вовсе не значит что их нужно обязательно создавать и что это есть хорошо

Циклические ссылки могут понадобиться, и не всегда это плохая архитектура. С++ получается ограничивает программиста, или заставляет его думать об освобождении памяти.

lpd>>Я бы предпочел вручную освобождение прописать, хотя если нравится RAII то могу понять.

CK>Явный new/delete или malloc/free в проекте на С++ это чаще всего code smell, нет реально ни одной причины для того, чтобы выделять и освобождать память или создавать и удалять объекты таким способом. Ты так предпочитаешь делать, ок, но для всех остальных в этом нет никакой логики, это просто код с душком.

Я предпочту сборку мусора явному delete/free. Однако городить unique_ptr<>/shared_ptr<> в простых случаях, где не нужен подсчет ссылок, значит делать освобождение памяти неявным без причины, да еще с неудобным синтаксисом. И вот это уже является слепым следованием за фанатиками вроде Майерса.

CK>там не удаление объектов тормозит, а поиск объектов, которые никто не использует и которые можно удалить
Тормозят объекты, выделяемые в большом количестве в цикле или массово. Их и можно удалять вручную, для ускорения сборки мусора. Где-то сборка мусора не подойдет, в таких проектах можно использовать free/delete или умные указатели.

Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, lpd, Вы писали:

lpd>>Во-вторых, RAII это не серебрянная пуля. Полно случаев когда он не описывает сложное владение объектом.

CK>это какие же?

Самое простое это неудобные случаи когда время жизни объекта не совпадает со временем жизни переменной.
И например может быть два объекта со счетчиками ссылок, которые нужно удалять вместе, или с более сложной логикой. Я понимаю, что можно исхитриться, но это же неудобно.
Вообще идея связывать время жизни переменной и какие-то операции по освобождению ресурсов довольно сомнительная. Время жизни переменной — это исключительно синтаксическая вещь, а освобождение ресурсов — императивная операция. И писать обертки над функциями только чтобы создать временную переменную, рассчитывая что где-то компилятор ее удалит, это удалять зубы через нос.

lpd>>Может это и ясно, но синтаксис у умных указателей очень громоздкий. И тут начнутся всякие auto, с которыми уже вообще ничего в коде не видно.

CK>Это чем же он громоздкий? Сишные st1->st2.fld3->st4 это значит не громоздко совсем, да?
Ну все эти unique_ptr<Type> по мне очень длинны если их писать по любому поводу, Type * всяко короче.

CK>с помощью ASan довольно тривиально, но вообще это не приходится делать, если правильно проектировать архитектуру, то бишь делать так, чтобы граф зависимостей объектов был ацикличным и направленным (это также неплохо помогает от дедлоков), то что сишечка позволяет иметь кучу циклических ссылок между объектами вовсе не значит что их нужно обязательно создавать и что это есть хорошо

Циклические ссылки могут понадобиться, и не всегда это плохая архитектура. С++ получается ограничивает программиста, или заставляет его думать об освобождении памяти.

lpd>>Я бы предпочел вручную освобождение прописать, хотя если нравится RAII то могу понять.

CK>Явный new/delete или malloc/free в проекте на С++ это чаще всего code smell, нет реально ни одной причины для того, чтобы выделять и освобождать память или создавать и удалять объекты таким способом. Ты так предпочитаешь делать, ок, но для всех остальных в этом нет никакой логики, это просто код с душком.

Я предпочту сборку мусора явному delete/free. Однако городить unique_ptr<>/shared_ptr<> в простых случаях, где не нужен подсчет ссылок, значит делать освобождение памяти неявным без причины, да еще с неудобным синтаксисом. И вот это уже является слепым следованием за фанатиками вроде Майерса.

CK>там не удаление объектов тормозит, а поиск объектов, которые никто не использует и которые можно удалить
Тормозят объекты, выделяемые в большом количестве в цикле или массово. Их и можно удалять вручную, для ускорения сборки мусора. Где-то сборка мусора не подойдет, в таких проектах можно использовать free/delete + умные указатели.