清洁。
当然，您可以不费心进行清理，让系统来处理。然而，如果这样做，您基本上无法追踪程序中的内存泄漏，因为您无法运行它并查看结束时是否有任何未分配的内容。另一方面，如果您确保干净的关闭，您可以通过运行程序并查看结束时是否有任何未分配的内容来知道是否存在任何泄漏。由于对于任何运行一段时间的非微不足道的程序，内存泄漏都是要避免的事情，因此以这种清洁的方式进行操作会带来好处。
此外，这也是确保您的程序以正确条件关闭并释放任何外部资源（虽然大多数现代操作系统都会在这些天自动清除），因为您正在进行有序的关闭而不仅仅是强制关闭程序。
不同的视角：
在程序结束时，通常没有特定的实际原因需要清理内存。但是对于不能放在单个页面上的非平凡程序，通常不会这样设计！程序的各个部分通常需要被设计成在程序执行的任何时间点都能够良好运行，而且通常不需要了解程序的其他部分。它们不能永久地分配和占用内存，因为一般来说，它们不知道自己会被调用多少次，后面会有多少代码跟随，或者持续多长时间。毕竟，许多最终用户应用程序都被设计为运行潜在无限的“主循环”。
因此，一个完全清理自己的程序并不是一个目标，而是从根本上正确设计整个程序的较小后果之一（强迫症者的奖励！）。如果在结束时还有资源剩余，它也可能作为某个设计过程阶段未按计划进行的警告标志。
你不能总是依赖系统，尽管大多数现代系统都这样做。据我所知，Windows 95没有这样做，因此可能还有一些野生的嵌入式系统也不会在进程结束后清理资源。
除此之外，这是一个好习惯。有时候你会将一些东西从main函数中重构到某些模块中并尝试重用它们。记得释放资源是很好的习惯。
没错。如果有一些对象将在整个应用程序的生命周期内存在，那么在启动时分配它一次并永远不释放/删除该对象是合理的。然而，如果您将某些东西分配为计算的一部分，并且没有必要保留该对象的整个生命周期，则重要的是在不再需要该对象时释放它；否则，随着对象在程序的生命周期中泄漏，您的程序将慢慢耗尽可用内存。
需要注意的是，即使您释放了内存，也总有可能在您有机会释放内存之前强制终止程序（例如通过信号）。因此，这是不必过于担心的一个原因。话虽如此，为了保持一致性和良好习惯，无论是常规分配/释放还是长期对象的分配/释放，我通常更喜欢像常规对象一样释放/清理长期对象。话虽如此，您应该平衡清理的愿望与快速关闭以及在强制关闭事件发生时能够生成正确的核心转储/日志的能力。例如，花时间释放大型长期数据结构可能会影响编写核心转储的时间，在这种情况下，编写核心转储可能更好。
