本文介绍了内存泄漏好吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在您的 C 或 C++ 应用程序中存在内存泄漏是否可以接受?>

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

如果第三方图书馆将这种情况强加给您怎么办?会拒绝使用该第三方库,无论它有多好?

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

解决方案

没有

作为专业人士,我们不应该问自己的问题是:这样做可以吗?"而是是否有好的理由这样做?"并且追查内存泄漏很痛苦"并不是一个很好的理由.

我喜欢保持简单.简单的规则是我的程序应该没有内存泄漏.

这也让我的生活变得简单.如果我检测到内存泄漏,我会消除它,而不是通过一些复杂的决策树结构来确定它是否是可接受的"内存泄漏.

它类似于编译器警告——警告对我的特定应用程序是致命的吗?也许不会.

但这归根结底是专业纪律问题.容忍编译器警告和容忍内存泄漏是一个坏习惯,最终会咬我.

将事情推向极端,外科医生将一些手术设备留在患者体内是否可以接受?

虽然可能会出现移除那件设备的成本/风险超过将其留在里面的成本/风险的情况,并且可能存在无害的情况,如果我看到这个问题发布在SurgeonOverflow.com 看到除了不"之外的任何答案,这将严重削弱我对医学界的信心.

如果第三方图书馆把这种情况强加给我,我会严重怀疑这个图书馆的整体质量.就好像我试驾了一辆车,在其中一个杯架上发现了几个松动的垫圈和螺母——这本身可能没什么大不了的,但它表现出对质量的缺乏承诺,所以我会考虑替代品.

Is it ever acceptable to have a memory leak in your C or C++ application?

What if you allocate some memory and use it until the very last line of code in your application (for example, a global object's destructor)? As long as the memory consumption doesn't grow over time, is it OK to trust the OS to free your memory for you when your application terminates (on Windows, Mac, and Linux)? Would you even consider this a real memory leak if the memory was being used continuously until it was freed by the OS.

What if a third party library forced this situation on you? Would refuse to use that third party library no matter how great it otherwise might be?

I only see one practical disadvantage, and that is that these benign leaks will show up with memory leak detection tools as false positives.

解决方案

No.

As professionals, the question we should not be asking ourselves is, "Is it ever OK to do this?" but rather "Is there ever a good reason to do this?" And "hunting down that memory leak is a pain" isn't a good reason.

I like to keep things simple. And the simple rule is that my program should have no memory leaks.

That makes my life simple, too. If I detect a memory leak, I eliminate it, rather than run through some elaborate decision tree structure to determine whether it's an "acceptable" memory leak.

It's similar to compiler warnings – will the warning be fatal to my particular application? Maybe not.

But it's ultimately a matter of professional discipline. Tolerating compiler warnings and tolerating memory leaks is a bad habit that will ultimately bite me in the rear.

To take things to an extreme, would it ever be acceptable for a surgeon to leave some piece of operating equipment inside a patient?

Although it is possible that a circumstance could arise where the cost/risk of removing that piece of equipment exceeds the cost/risk of leaving it in, and there could be circumstances where it was harmless, if I saw this question posted on SurgeonOverflow.com and saw any answer other than "no," it would seriously undermine my confidence in the medical profession.

If a third party library forced this situation on me, it would lead me to seriously suspect the overall quality of the library in question. It would be as if I test drove a car and found a couple loose washers and nuts in one of the cupholders – it may not be a big deal in itself, but it portrays a lack of commitment to quality, so I would consider alternatives.

这篇关于内存泄漏好吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-29 00:31