在C或c++应用程序中出现内存泄漏是可以接受的吗?

如果分配一些内存并一直使用到应用程序中的最后一行代码(例如,全局对象的析构函数),会怎样?只要内存消耗不随时间增长,那么当应用程序终止时(在Windows、Mac和Linux上),是否可以信任操作系统为您释放内存?如果内存一直被使用,直到被操作系统释放,您会认为这是真正的内存泄漏吗?

如果是第三方库将这种情况强加给您,该怎么办?会拒绝使用第三方库,不管它有多好?

我只看到了一个实际的缺点,那就是这些良性泄漏将在内存泄漏检测工具中显示为误报。


当前回答

这实际上取决于创建内存泄漏的对象的使用情况。 如果在使用该对象的应用程序的生命周期内多次创建该对象,那么使用这种方式是不好的。因为会有很多内存泄漏。 另一方面,如果我们有一个对象的实例,不消耗内存,只泄漏少量,那么这不是一个问题。

当应用程序运行时内存泄漏增加时,内存泄漏就是一个问题。

其他回答

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

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

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

理论上没有,实际情况要视情况而定。

这实际上取决于程序处理了多少数据,程序运行的频率以及它是否持续运行。

如果我有一个快速程序,读取少量数据进行计算并退出,那么就永远不会注意到一个小的内存泄漏。因为程序不会运行很长时间,并且只使用少量的内存,所以当程序存在时,泄漏将很小并被释放。

另一方面,如果我有一个处理数百万条记录并运行很长时间的程序,一个小的内存泄漏可能会在足够的时间内使机器停机。

对于有泄漏的第三方库,如果它们导致问题,要么修复库,要么找到更好的替代方案。如果不造成问题,这真的重要吗?

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

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