在C或c++应用程序中出现内存泄漏是可以接受的吗?
如果分配一些内存并一直使用到应用程序中的最后一行代码(例如，全局对象的析构函数)，会怎样?只要内存消耗不随时间增长，那么当应用程序终止时(在Windows、Mac和Linux上)，是否可以信任操作系统为您释放内存?如果内存一直被使用，直到被操作系统释放，您会认为这是真正的内存泄漏吗?
如果是第三方库将这种情况强加给您，该怎么办?会拒绝使用第三方库，不管它有多好?
我只看到了一个实际的缺点，那就是这些良性泄漏将在内存泄漏检测工具中显示为误报。
当前回答
这个问题已经讨论得令人作呕了。最重要的是，内存泄漏是一个bug，必须修复。如果第三方库泄露了内存，就会让人怀疑它还有什么问题，不是吗?如果你要造一辆汽车，你会使用一个偶尔漏油的发动机吗?毕竟，引擎是别人做的，所以这不是你的错，你不能修，对吧?
其他回答
我想，如果你正在编写一个打算泄漏内存的程序(即测试内存泄漏对系统性能的影响)，这是没有问题的。
只有一种情况:由于不可恢复的错误，程序将自行终止。
我很惊讶看到这么多关于内存泄漏的错误定义。如果没有一个具体的定义，关于它是否是坏事的讨论就不会有任何结果。
正如一些评论员正确地指出的那样，只有当进程分配的内存超出作用域，以至于该进程不再能够引用或删除它时，才会发生内存泄漏。
A process which is grabbing more and more memory is not necessarily leaking. So long as it is able to reference and deallocate that memory, then it remains under the explicit control of the process and has not leaked. The process may well be badly designed, especially in the context of a system where memory is limited, but this is not the same as a leak. Conversely, losing scope of, say, a 32 byte buffer is still a leak, even though the amount of memory leaked is small. If you think this is insignificant, wait until someone wraps an algorithm around your library call and calls it 10,000 times.
我认为没有任何理由允许在您自己的代码中泄漏，无论多么小。现代编程语言，如C和c++，不遗余力地帮助程序员防止此类泄漏，并且很少有好的理由不采用好的编程技术——特别是在与特定的语言功能相结合时——来防止泄漏。
对于现有的或第三方代码，您对质量的控制或进行更改的能力可能非常有限，这取决于泄漏的严重程度，您可能被迫接受或采取缓解措施，例如定期重新启动进程以减少泄漏的影响。
更改或替换现有的(泄漏的)代码可能是不可能的，因此您可能不得不接受它。然而，这并不等同于宣称它是OK的。
我想以你的情况，答案可能是没关系。但是您肯定需要记录内存泄漏是一个有意识的决定。你不希望一个维护程序员出现，把你的代码放到一个函数中，然后调用它一百万次。因此，如果您决定泄漏是可以接受的，那么您需要为将来可能不得不在该程序上工作的任何人记录它(用大写字母)。
如果这是一个第三方库，你可能会被困住。但是一定要记录泄漏的发生。
但基本上，如果内存泄漏是一个已知的数量，比如512 KB的缓冲区，那么它就不是问题。如果内存泄漏持续增长，比如每次调用库调用时，内存都会增加512KB，但没有释放，那么可能有问题。如果您记录它并控制调用执行的次数，那么它可能是可管理的。但是你真的需要文档，因为虽然512不是很多，但是512超过一百万次调用就很多了。
此外，您还需要检查您的操作系统文档。如果这是一个嵌入式设备，那么操作系统可能不会从退出的程序中释放所有内存。我不确定，也许这不是真的。但这是值得研究的。
我相信有人能想出一个理由说“是”，但不会是我。 与其说“不”，我要说的是，这不应该是一个“是”或“否”的问题。 有许多方法可以管理或控制内存泄漏，许多系统都有内存泄漏。
在离开地球的设备上有NASA的系统为这个做了计划。系统会经常自动重启，这样内存泄漏就不会对整体操作造成致命影响。这只是一个遏制的例子。
