我相信有人能想出一个理由说“是”，但不会是我。 与其说“不”，我要说的是，这不应该是一个“是”或“否”的问题。 有许多方法可以管理或控制内存泄漏，许多系统都有内存泄漏。

在离开地球的设备上有NASA的系统为这个做了计划。系统会经常自动重启，这样内存泄漏就不会对整体操作造成致命影响。这只是一个遏制的例子。

我在高中上过一门C课，老师说当你malloc的时候一定要确保自由。

但是当我在大学里上另一门课的时候，教授说对那些只运行一秒钟的小程序不免费是可以的。 因此，我认为这不会损害您的程序，但免费提供强大、健康的代码是一种很好的实践。

我同意vfilby -这要看情况。在Windows中，我们将内存泄漏视为相对严重的错误。但是，这很大程度上取决于分量。

例如，对于很少运行且运行时间有限的组件，内存泄漏不是很严重。这些组件运行，完成工作，然后退出。当它们退出时，所有内存都被隐式释放。

但是，服务或其他长期运行组件(如shell)中的内存泄漏非常严重。原因是这些bug会随着时间的推移“窃取”内存。恢复的唯一方法是重新启动组件。大多数人不知道如何重新启动服务或shell——所以如果他们的系统性能受到影响，他们就重新启动。

所以，如果你有一个泄漏-评估它的影响两种方式

你的软件和你的用户体验。 对于系统(和用户)来说，节省系统资源是非常重要的。 修复对维护和可靠性的影响。 在其他地方造成倒退的可能性。

前甲板

在应用程序运行后清理操作系统在概念上没有问题。

这实际上取决于应用程序以及它将如何运行。在需要运行数周的应用程序中不断发生的泄漏必须得到处理，但是一个不需要太多内存就能计算结果的小工具应该不是问题。

许多脚本语言不垃圾收集循环引用是有原因的……对于它们的使用模式，这不是一个实际的问题，因此浪费的资源和浪费的内存一样多。

看来你对“内存泄漏”的定义是“我自己不清理的内存”。所有现代操作系统都会在程序退出时释放它。然而，由于这是一个c++问题，您可以简单地将所讨论的内存包装在适当的std::auto_ptr中，当它超出作用域时将调用delete。

不，它们不是可以的，但是我已经实现了一些分配器、内存转储器和泄漏检测器，并且发现从实用的角度来看，允许人们将这样的分配标记为“就泄漏报告而言，不是泄漏”是很方便的……

这有助于使泄漏报告更有用……不要充斥着“静态范围内的动态分配不被程序退出释放”