我想以你的情况，答案可能是没关系。但是您肯定需要记录内存泄漏是一个有意识的决定。你不希望一个维护程序员出现，把你的代码放到一个函数中，然后调用它一百万次。因此，如果您决定泄漏是可以接受的，那么您需要为将来可能不得不在该程序上工作的任何人记录它(用大写字母)。

如果这是一个第三方库，你可能会被困住。但是一定要记录泄漏的发生。

但基本上，如果内存泄漏是一个已知的数量，比如512 KB的缓冲区，那么它就不是问题。如果内存泄漏持续增长，比如每次调用库调用时，内存都会增加512KB，但没有释放，那么可能有问题。如果您记录它并控制调用执行的次数，那么它可能是可管理的。但是你真的需要文档，因为虽然512不是很多，但是512超过一百万次调用就很多了。

此外，您还需要检查您的操作系统文档。如果这是一个嵌入式设备，那么操作系统可能不会从退出的程序中释放所有内存。我不确定，也许这不是真的。但这是值得研究的。

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

只有一种情况:由于不可恢复的错误，程序将自行终止。

我相信答案是否定的，永远不要允许内存泄漏，我有一些我没有看到明确说明的原因。这里有很好的技术答案，但我认为真正的答案取决于更多的社会/人类原因。

(首先，请注意，正如其他人所提到的，真正的泄漏是当您的程序在任何时候失去对已分配内存资源的跟踪时。在C语言中，当你malloc()指向一个指针并让该指针离开作用域而没有先执行free()时，就会发生这种情况。

你做决定的关键在于习惯。当你用一种使用指针的语言编写代码时，你会经常使用指针。指针是危险的;它们是向代码中添加各种严重问题的最简单方法。

当你在编程的时候，有时你会很专注，有时你会很累、生气或担心。在那些有点分心的时间里，你会更多地自动编码。自动驾驶效果不会区分一次性代码和大型项目中的模块。在此期间，您所建立的习惯将最终出现在您的代码库中。

所以，不，永远不要允许内存泄漏，就像你在换车道时仍然应该检查盲点一样，即使你是路上唯一的车。当你活跃的大脑分心时，好习惯可以让你避免灾难性的失误。

除了“习惯”问题之外，指针是复杂的，通常需要大量的脑力来在精神上跟踪。当涉及到指针的使用时，最好不要“搅浑水”，特别是当您是编程新手时。

还有更多的社交方面。通过正确使用malloc()和free()，任何查看您的代码的人都会感到轻松;你在管理你的资源。然而，如果你不这样做，他们马上就会怀疑有问题。

也许您已经发现内存泄漏在这种情况下不会造成任何损害，但是代码的每个维护者在阅读这段代码时也必须在自己的头脑中解决这个问题。通过使用free()，您甚至不需要考虑这个问题。

最后，编程是用一种明确的语言编写一个过程的心理模型，这样人和计算机就可以完全理解所述过程。好的编程实践的一个重要部分是永远不要引入不必要的歧义。

智能编程是灵活和通用的。糟糕的编程是模棱两可的。

如果分配内存并一直使用到程序的最后一行，这就不是泄漏。如果您分配内存并忘记它，即使内存数量没有增长，这也是一个问题。已分配但未使用的内存可能导致其他程序运行速度变慢或根本不运行。

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

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

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

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

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

前甲板