在C或c++应用程序中出现内存泄漏是可以接受的吗?
如果分配一些内存并一直使用到应用程序中的最后一行代码(例如，全局对象的析构函数)，会怎样?只要内存消耗不随时间增长，那么当应用程序终止时(在Windows、Mac和Linux上)，是否可以信任操作系统为您释放内存?如果内存一直被使用，直到被操作系统释放，您会认为这是真正的内存泄漏吗?
如果是第三方库将这种情况强加给您，该怎么办?会拒绝使用第三方库，不管它有多好?
我只看到了一个实际的缺点，那就是这些良性泄漏将在内存泄漏检测工具中显示为误报。
当前回答
当应用程序关闭时，可以认为最好不要释放内存。
理论上，操作系统应该释放应用程序使用的资源，但总有一些资源是这个规则的例外。所以要小心。
退出应用程序的好处是:
操作系统只释放一个块，而不是很多很多小块。这意味着关机速度要快得多。尤其是在内存管理缓慢的Windows上。
只是退出的坏处其实有两点
很容易忘记释放操作系统没有跟踪的资源，或者操作系统可能会等待一段时间才释放。一个例子是TCP套接字。 内存跟踪软件将报告在退出时未释放的所有内容为泄漏。
因此，您可能希望有两种关机模式，一种是针对最终用户的快速且不友好的关机模式，另一种是针对开发人员的缓慢且彻底的关机模式。只是要确保两者都测试:)
其他回答
我相信有人能想出一个理由说“是”，但不会是我。 与其说“不”，我要说的是，这不应该是一个“是”或“否”的问题。 有许多方法可以管理或控制内存泄漏，许多系统都有内存泄漏。
在离开地球的设备上有NASA的系统为这个做了计划。系统会经常自动重启，这样内存泄漏就不会对整体操作造成致命影响。这只是一个遏制的例子。
一般情况下，如果遇到无法避免的内存泄漏，则需要更加认真地考虑对象所有权问题。
但对于你的问题，我的回答是在产品代码中，是的。在开发过程中，没有。这听起来可能有些倒退，但我的理由是:
In the situation you describe, where the memory is held until the end of the program, it's perfectly okay to not release it. Once your process exits, the OS will clean up anyway. In fact, it might make the user's experience better: In a game I've worked on, the programmers thought it would be cleaner to free all the memory before exiting, causing the shutdown of the program to take up to half a minute! A quick change that just called exit() instead made the process disappear immediately, and put the user back to the desktop where he wanted to be.
但是，您对调试工具的看法是正确的:它们会突然发作，而且所有的假阳性可能会使查找真正的内存泄漏变得很痛苦。正因为如此，总是编写释放内存的调试代码，并在发布时禁用它。
考虑这样一种情况，该应用程序后来从另一个应用程序中使用，可以在单独的窗口中打开其中的几个应用程序，也可以依次打开其中的几个应用程序来执行某些操作。如果它不是作为一个进程运行，而是作为一个库运行，那么调用程序会泄漏内存，因为您以为您冷跳过了内存清理。
使用一些智能指针，自动为你做(例如scoped_ptr从Boost库)
也许是在细枝末节:如果您的应用程序运行在UNIX上，可能会变成僵尸怎么办?在这种情况下，内存不会被操作系统回收。所以我说你应该在程序退出之前重新分配内存。
这实际上取决于创建内存泄漏的对象的使用情况。 如果在使用该对象的应用程序的生命周期内多次创建该对象，那么使用这种方式是不好的。因为会有很多内存泄漏。 另一方面，如果我们有一个对象的实例，不消耗内存，只泄漏少量，那么这不是一个问题。
当应用程序运行时内存泄漏增加时，内存泄漏就是一个问题。
