Почему использование exit() считается плохой?
Я читаю этот вопрос, и есть ответ, объясняющий, почему использование exit()
плохо, потому что:
- В результате у вас будет несколько точек выхода из программы
- Он делает код более запутанным (например, с помощью goto)
- Он не может освободить память, выделенную во время выполнения
Я должен уточнить, что я использую Qt, поэтому код уже немного "запутан", так как я использую сигналы и слоты. При этом, для вопроса № 1, я вижу, что это связано с №2, но мой код в настоящее время пытается избежать использования exit()
, потому что мне сказали, что это сделает мой код похожим на беспорядок, но избегать exit
сделал это беспорядок. У меня есть функции, которые не должны ничего возвращать, возвращая вещи. Например, когда у меня есть регистрация пользователей, и их имя пользователя уже существует, вместо того, чтобы просто вызвать exit()
после того, как пользователь не выполнил регистрацию пользователя (что является желательным поведением в этой ситуации), я возвращаю false
к функции, которая возвращает false
к другой функции, которая затем возвращает false
в мою основную часть, которая затем проверяет, вернулась ли эта функция true или false, и если она возвращает false, то она возвращает 0. Так много, чтобы избежать exit()
сделать код чистым.
Для третьей проблемы, не используя exit(0)
, сообщите ОС, что программа выполнена, и ОС освободит эту память в любом случае? Я запускал тестовый пример, который использует exit(0)
, когда я нажимаю кнопку, и процесс удаляется из списка процессов, и память освобождается, так почему же это даже проблема? Кажется, это откровенное ложное утверждение, по крайней мере, в Windows.
Ответы
Ответ 1
Просто слепой вызов exit()
где-то в вашей программе считается плохим по простой причине:
Он не закрывает должным образом другие потоки (они просто прекращаются), он не очищает должным образом все буферы (очищаются файлы stdio) и гарантирует согласованное и действительное состояние постоянных/общих ресурсов (файлов/общей памяти/других способов связи).
Тем не менее, если вы можете гарантировать, что не запущен ни один поток, который мог бы помешать (будучи убитым удерживанием блокировки или чего-то подобного), и все буферы, которые в нем нуждаются, будут очищены exit()
, то это верный способ добиться более быстрого выключения.
Многие современные программы запрограммированы для еще более быстрого выключения:
Он устойчив к сбоям, почти каждый раз просто выключается, например, с помощью _Exit()
(даже не вызывая atexit
или at_quick_exit
зарегистрированных хуков) в порядке. В большинстве случаев это намного быстрее, чем упорядоченное завершение работы (если возможно, ресурсы пользовательского интерфейса Windows следует сначала уничтожить, поскольку они являются исключением).
Для дальнейшего чтения: Crash-only software (PDF!)
Только сбойные программы аварийно завершают работу и быстро восстанавливаются. Есть только один способ остановить такое программное обеспечение - сбой это - и только один способ поднять это - путем восстановления. Системы, предназначенные только для сбоев, построены из компонентов, предназначенных только для сбоев, и использование прозрачных повторений на уровне компонентов скрывает внутрисистемные сбои компонентов от конечных пользователей. В В этой статье мы выступаем за отказоустойчивый дизайн для интернет-систем, показывая, что это может привести к более надежным, предсказуемым код и быстрее, более эффективное восстановление. Мы представляем идеи о том, как построить такие краш-интернет-сервисы, принимая удачные приемы до логического предела.
Ответ 2
Пункты 1 и 2, я не согласен. Это больше вопросов стиля и предпочтений.
Что касается пункта 3, вы должны посмотреть документацию, чтобы увидеть, что она на самом деле будет или не будет бесплатной или флешей (http://en.cppreference.com/w/cpp/utility/program/exit и http://msdn.microsoft.com/en-us/library/6wdz5232.aspx). Например, в документации MS говорится: "Сбрасывает все буферы файлов до того, как он завершит процесс".
Когда ваша программа выйдет, ОС вернет память, но это не то, о чем он говорит. Он имеет в виду, что такие ресурсы, как семафоры, не будут выпущены должным образом или своевременно. Может быть, это проблема, возможно, нет, в зависимости от того, какие ресурсы вы используете.