我应该在exception终止时释放分配的内存吗？

我的程序（文本模式Web浏览器）动态分配内存。

当然，我在运行时释放不需要的块。并且我在正常终止之前释放所有内容 – 因此内存泄漏检查器不会给我误报（并且如果需要重大重构则要灵活）。

现在，我不做的是在exception终止之前释放内存。（目前，我的程序在信号和mallocs / reallocs失败后终止。）

我的问题是：你认为这种不好的风格吗？我应该在exception终止时免费吗？

不，我认为在程序终止后，简单地举手并让操作系统回收内存是完全可以接受的。我认为如果这是一个真正的exception情况并且意图是让程序终止，那么一个行为良好的程序应该只是清理任何磁盘资源/锁，并尽快退出。

在我看来，没有必要释放崩溃的内存。当您的进程终止时，操作系统将回收内存，因此您所要做的就是退出。

另一方面，其他资源（例如打开文件）应该关闭或至少刷新 – 否则，由于缓冲，它们可能不会被存储/存储不完整。

除了避免泄漏检测工具中的误报外，您无需在正常终止时回收内存。

如果您的程序exception终止，根据原因，您可能会发现无法释放内存。例如，由于堆损坏导致的SIGSEGV意味着即使尝试释放堆上的其他东西也许是一个无望的练习。

exception终止进程不会导致其他进程无法使用的内存块（实际上意味着它们是空闲的），如果它们是由它分配的。

我们使用OS指令分配/释放内存，以便非错误的操作系统跟踪每个进程的mem块并将它们转换为连续的虚拟内存空间。在进程死亡时，OS加载程序发出信号，并且所有内存都会被调用。当进程共享内存时，事情变得复杂。

对等进程，如果没有由您进行派生/启动/分叉（例如，考虑服务于许多进程以访问多媒体资源的外部组件），可能已经创建了内存（例如缓冲区）来为您的进程提供服务。根据这些外部组件的所有权政策，在服务进程死亡时，该内存可能不是免费的。

我建议您尝试审核在exception终止方案之前和之后提交的所有内存。

不，除非您的程序总是exception终止。 :)无论如何，操作系统可以很好地释放它。事实上，许多懒惰的程序员甚至都没有通过正常终止来解决问题 – 但这使得检测其他内存泄漏变得困难（那些是真正的问题）。

仅当您的操作系统在程序终止时不回收内存时。 DOS及其“粘性存储器”就是这种操作系统的一个例子。在大多数现代操作系统上，不是免费的（）exception终止是一个非问题。

在exception终止时，您希望尽可能少地处理。最大限度地减少对中止过程的修改将意味着您可以尽可能接近中止的原因，任何进一步的处理都可以被视为“污染”过程，从而使调试更加困难。