Dv
Есть штука, которую спека языка ранее называла «деструктором», но больше не называет. Сейчас это называют «финализатор». И не считается хорошим тоном полагаться на них вообще.
Size: a a a
2021 July 26
Dv
Есть сценарии, в которых они могут быть не вызваны при завершении приложения.
EP
да, вот примерно я об этом
Dv
К слову, я и там не знаю способа вызвать код на выгрузке DLL из памяти.
Dv
Хотя наверняка можно. Но пользоваться не доводилось, да и надобности такой не было. Обычно все ресурсы, которым нужна гарантированная инициализация/деинициализация, складывают в какой-нибудь dependency scope, а дальше уже контейнер этим управляет.
При этом предполагается, что такие ресурсы не должны быть объявлены как статики.
При этом предполагается, что такие ресурсы не должны быть объявлены как статики.
D
Вроде в винде есть DllMain и типа того же?
Dv
Ну в нативных либах есть, да. И как раз вот там можно написать ручной код по деинициализации всяких статиков и т.п.
D
Угу
Dv
Но это довольно стрёмная тема. Множество ограничений у кода, который выполняется в
DllMain.А⚙
Такого рода — да, сложно. Ибо я вообще не вижу причин писать настолько хрупкий код
Dv
Хз что хрупкого в рекурсивной лямбде. Мне вот сложно это понять.
D
Вроде как человеческие либы предоставляют всякие init/fini API
D
ЧТобы никакого блядства не воротить
Dv
Ну да, обычно, если у тебя плугабельная инфраструктура с динамической загрузкой плагинов (что довольно редко бывает, кажется?), то тогда лучше всего явно выдать API для инициализации и деинициализации плагинов.
А⚙
Как я уже говорил: это ненормально, что отсутствует/наличие UB зависит от факта (не)вызова функции. А так как объект захватывается по ссылке, его потом ещё и перемещать нельзя, поскольку это ссылку инвалидирует
Dv
Я не понимаю, что ты там несёшь про UB.
Dv
В рекурсивной лямбде, кажется, никакого UB нет?
EP
о чём речь? о рекурсивных лямбдах? я использую
Dv
Да больной тут какой-то.
Dv
Я уже присматриваюсь, как его ловчее упаковать.