История изменений

А ещё кто-то переопределит std::terminate_handler и ничего не завершится).

По умолчанию, хендлер - std::abort() aka просто abort(), который в случае юниксов вынудит ядро послать процессу SIGABRT.

По поводу exit(). Не хочешь звать exit()… вызови std::exit() :-D

Если коротко, то вызовутся деструкторы для всех объектов со статическим времени жизни, которые были созданы: std::exit().

Деструкторы объектов с динамическим временем жизни (грубо: созданными через new) вызваны не будут. Но ты можешь зарегистрировать функцию очтистки через std::atexit().

Сложнее с объектами, со автоматическим временем жизни, т.е. обычными объектами, созданными на стеке: у нас не будет выхода за пределы области видимости (возврата из функции std::exit() нет), а значит и условие вызова деструктора не выполняется.

С тредами тоже нюанс: если дойдёт дело до деструктора std::thread, а тред в работе, то вылетит исключение и тогда уже будет или обработка оного с твоей стороны или std::terminate().

И всё выше верно для всех вариантов выхода, минуя выход через return из main(). Отсюда и варианты:

1. коды ошибок и возвращаться наверх в main() и там делать return.
2. вместо exit() - бросать исключение и ловить его на самом верху (в треде - в функции треда), при исключении стек раскручивается и деструкторы гарантированно вызываются

Это про решения в лоб, а дальше задаться вопросом:

А что будет если у автоматического объекта не вызовется деструктор?

• Если открыт файл - его закроет файловая система
• Аналогично с сокетом
• Память тоже после смерти процесса система вернёт

Если же есть какие-то чувствительные данные (затереть ключи и пароли в памяти перед выходом, SHM почистить/освободить, всякие gpio с state-full реализацией (через /sys) вернуть в нужное состояние, etc), которые нужно гарантированно чистить, то тут однозначно нужен хендлер через std::atexit() или через RAII объект со статическим временем жизни.

С тредами тоже: нужно сигналить и завершаться. А может и не нужно, и просто быстро выходить. Всё зависит от твоих данных.

В общем, как видно - безопасности, далеко не всегда про скорость :)

А ещё кто-то переопределит std::terminate_handler и ничего не завершится).

По умолчанию, хендлер - std::abort() aka просто abort(), который в случае юниксов вынудит ядро послать процессу SIGABRT.

По поводу exit(). Не хочешь звать exit()… вызови std::exit() :-D

Если коротко, то вызовутся деструкторы для всех объектов со статическим времени жизни, которые были созданы: std::exit().

Деструкторы объектов с динамическим временем жизни (грубо: созданными через new) вызваны не будут. Но ты можешь зарегистрировать функцию очтистки через std::atexit().

Сложнее с объектами, со автоматическим временем жизни, т.е. обычными объектами, созданными на стеке: у нас не будет выхода за пределы области видимости (возврата из функции std::exit() нет), а значит и условие вызова деструктора не выполняется.

С тредами тоже нюанс: если дойдёт дело до деструктора std::thread, а тред в работе, то вылетит исключение и тогда уже будет или обработка оного с твоей стороны или std::terminate().

И всё выше верно для всех вариантов выхода, минуя выход через return из main(). Отсюда и варианты:

1. коды ошибок и возвращаться наверх в main() и там делать return.
2. вместо exit() - бросать исключение и ловить его на самом верху (в треде - в функции треда), при исключении стек раскручивается и деструкторы гарантированно вызываются

Это про решения в лоб, а дальше задаться вопросом:

А что будет если у автоматического объекта не вызовется деструктор?

• Если открыт файл - его закроет файловая система
• Аналогично с сокетом
• Память тоже после смерти процесса система вернёт

Если же есть какие-то чувствительные данные (затереть ключи и пароли в памяти перед выходом), которые нужно гарантированно чистить, то тут однозначно нужен хендлер через std::atexit() или через RAII объект со статическим временем жизни.

С тредами тоже: нужно сигналить и завершаться. А может и не нужно, и просто быстро выходить. Всё зависит от твоих данных.

В общем, как видно - безопасности, далеко не всегда про скорость :)