Question

有一类以这种方式工作的短期生活计划：

1. Allocate some resources - memory, open files, etc.
2. Make some computations
3. Free allocated resources
4. Terminate

同样的问题对于类型的长期计划的终止阶段是有效的：

1. Do some job
2. If not the end - goto 1
3. Free the resources still allocated
4. Terminate

现在，我们知道操作系统本身在程序终止后总是会清理。是否真的有必要通过我们的代码来清理已分配的内存，如果它会以相同的成功，由操作系统释放，更进一步？

我们能否安全地省略上述例子中的第3点？毕竟是时间和代码。

澄清1 ：我不是在谈论代码可以被不同环境中的某个人重用的库。我问的是完成的程序，上面的结构足够干净。

澄清2 ：所谓“良好做法”，因为它们旨在防止“不良影响”。但如果不可能发生不良影响，这些做法仍然“好”吗？或者它只是“传统”？

Answer 1

这在很大程度上取决于操作系统。当程序终止时，大多数现代操作系统将自动释放所有资源，这意味着在退出程序之前没有实际要求释放内容。

但这不是总是的情况，特别是某些类型的嵌入式操作系统将采用更简单的方法。

当然，当你（或者更重要的是，其他人）决定接受你的代码并将其从一个短暂的运行过程转变为一个长期存在的程序时，它也不能很好地工作......

Answer 2

我认为对此没有真正有意义的语言无关的答案。

在使用垃圾收集器的语言中，GC不可能在退出之前自动运行，并且手动强制它运行通常是毫无意义的（即使我们假设您正在使用允许使用的语言/库你这样做了。）

在C ++中，资源获取几乎总是在构造函数中发生，并且释放该资源通常应该在匹配的析构函数中发生。在这种情况下，编写没有正确析构函数的代码几乎肯定是一个错误 - 你只是编写一个不完整的类，并希望它只会以一种方式使用，以防止错误显现。

在C或其他类似的手动清理的地方，我更喜欢编写代码来进行最后的清理，但通常将其注释掉。这可以提高速度和代码大小，并确保代码中的任何错误都可以释放数据（对于未编译导致问题的代码来说非常困难）。

Answer 3

你应该总是自己清理干净。你永远不知道有人会在不同情况下使用你的代码并使用它。

在所有情况下编写完整的解决方案是正确的。

Answer 4

我在某个时候也问过自己这个问题，经过一番小小的辩论后我得出结论：

如果您决定稍后在较大的项目中重用该代码，则最好释放资源。调试旧代码没有什么比这更糟的了。立即行动并坚持良好的编程习惯。