内存泄漏是否有可接受的限制？
我刚刚开始在C ++中尝试SDL，并且我认为定期检查内存泄漏可能是早期形成的良好习惯。
考虑到这一点，我一直在通过Valgrind运行我的'Hello world'程序来捕获任何泄漏，虽然除了最基本的SDL_Init()和SDL_Quit()语句之外，我已经删除了所有内容，但Valgrind仍然报告丢失了120个字节， 77k仍可到达。
我的问题是：是否有可接受的内存泄漏限制，还是应该努力使我的所有代码完全无泄漏？
小心Valgrind在测量中不会出现误报。
许多内存分析器的天真实现标志着当内存泄漏事件不是真的时会将泄漏的内存标记为泄漏。
也许可以阅读关于Purify的维基百科文章的外部链接部分的一些论文。 我知道Purify附带的文档介绍了几种在尝试检测内存泄漏时获得误报的场景，然后继续描述Purify用来解决问题的技术。
顺便说一句，我不以任何方式与IBM有任何关系。 我刚刚使用Purify广泛，并会保证其有效性。
编辑：这是一篇关于内存监控的优秀介绍性文章。 这是Purify的具体内容，但关于内存错误类型的讨论非常有趣。
HTH。
干杯，
抢
你必须小心“内存泄漏”的定义。 某些在第一次使用时分配一次，并在程序退出时释放的东西有时会由泄漏检测器显示出来，因为它在第一次使用之前开始计数。 但这不是泄漏（尽管这可能是糟糕的设计，因为它可能是某种全球性的）。
要查看给定的代码块是否泄漏，可以合理运行一次，然后清除泄漏检测器，然后再次运行（这当然需要对泄漏检测器进行编程控制）。 每次运行程序“泄漏”一次通常不重要。 每次执行“泄漏”的事情通常最终都会很重要。
我很少发现在这个指标上达到零就太困难了，这相当于观察了蠕变的内存使用情况，而不是丢失的数据块。 我有一个图书馆，它非常复杂，带有缓存和UI家具，而且我只用三次运行我的测试套件，忽略了没有出现在三个块的倍数中的任何“泄漏”。 我仍然抓住了所有或几乎所有的实际泄漏事件，并且一旦我得到了唾手可得的成果，就分析了棘手的报告。 当然，为此目的使用测试套件的缺点是（1）只能使用不需要新进程的部分，（2）您发现的大部分泄漏都是测试代码的错误，而不是库代码...
生活在内存泄漏（和其他粗心的问题），最好的（在我看来）是非常糟糕的编程。 最糟糕的是它使软件无法使用。
您应该首先避免介绍它们，并运行您和其他人提到的工具来尝试检测它们。
避免马虎编程 - 已经有足够多坏程序员 - 世界不需要另一个。
编辑
我同意 - 许多工具可以提供误报。
链接地址: http://www.djcxy.com/p/19917.html