我正在阅读 this question并且有一个答案可以解释为什么使用exit()是错误的,因为：
>您最终会从程序中获得多个退出点
>它使代码更复杂(比如使用goto)
>它无法释放在运行时分配的内存
我应该澄清我正在使用Qt,所以代码已经有点“复杂”,因为我正在利用信号和插槽.话虽这么说,对于问题#1,我看到它与#2有关,但我的代码目前试图避免使用exit(),因为我被告知它会让我的代码看起来像一团糟,但避免退出使它成为一个一塌糊涂.我有一些功能,不需要返回任何东西,返回东西.例如,当我有用户注册并且他们的用户名已经存在时,而不是在告知用户注册失败后(在这种情况下这是期望的行为)之后调用exit(),我将false返回给一个函数,然后该函数返回false给另一个函数然后返回false给我的main然后检查该函数是返回true还是false,如果它返回false则返回0.这样就避免了exit()使代码干净.
对于第三个问题,不使用exit(0)告诉操作系统该程序是否已完成运行并且操作系统将自行释放该内存？我运行了一个使用exit(0)的测试用例,当我按下一个按钮并从进程列表中删除进程并释放内存时,为什么这甚至是一个问题呢？这似乎是一个彻头彻尾的错误陈述,至少在Windows上.
解决方法
它没有正确关闭其他线程(它们刚刚被终止),它没有正确刷新所有缓冲区(stdio文件被刷新)并保证永久/共享资源的一致和有效状态(文件/共享内存/其他通信方式) .
尽管如此,如果你可以保证没有正在运行的线程可能会干扰(通过被锁等等),并且所有需要它的缓冲区都将被exit()刷新,这是实现更快关闭的有效方法.
许多现代软件都经过编程,可以更快地关闭：
它是容易崩溃的,因为几乎每次都只能使用例如关闭它来关闭. _Exit()(甚至不调用atexit或at_quick_exit注册的钩子)都可以.在大多数情况下,这比有序关闭快得多(如果可能,应首先销毁Windows用户界面资源,因为它们是例外).
进一步阅读：Crash-only software (PDF!)
Crash-only programs crash safely and recover quickly. There is only one way to stop such software – by crashing it – and only one way to bring it up – by initiating recovery. Crash-only systems are built from crash-only components,and the use of transparent component-level retries hides intra-system component crashes from end users. In this paper we advocate a crash-only design for Internet systems,showing that it can lead to more reliable,predictable code and faster,more effective recovery. We present ideas on how to build such crash-only Internet services,taking successful techniques to their logical extreme.
