我是Windows平台上的c++程序员。我使用的是Visual Studio 2008。
我通常会在代码中出现内存泄漏。
通常我通过检查代码来发现内存泄漏，但这很麻烦，而且并不总是一种好方法。
因为我买不起付费的内存泄漏检测工具，所以我想让你们建议避免内存泄漏的最佳方法。
我想知道如何程序员可以找到内存泄漏。 是否应该遵循某种标准或过程来确保程序中没有内存泄漏?
当前回答
在Windows上，你可以使用CRT调试堆。
是否有任何标准或程序可以确保程序中没有内存泄漏。
是的，不要使用手动内存管理(如果你曾经手动调用delete或delete[]，那么你做错了)。使用RAII和智能指针，将堆分配限制到绝对最小值(大多数时候，自动变量就足够了)。
其他回答
运行“Valgrind”可以:
1)帮助识别内存泄漏-显示您有多少内存泄漏，并指出代码中泄漏内存分配的行。
2)指出错误的释放内存的尝试(例如不正确的delete调用)
“Valgrind”使用说明
1)在这里获得valgrind。
2)使用-g标志编译代码
3)在shell中运行:
valgrind --leak-check=yes myprog arg1 arg2
其中"myprog"是你编译的程序，arg1, arg2是你程序的参数。
4)结果是一个调用malloc/new的列表，没有后续调用free delete。
例如:
==4230== at 0x1B977DD0: malloc (vg_replace_malloc.c:136)
==4230== by 0x804990F: main (example.c:6)
告诉您在哪一行(未释放的)调用了malloc。
正如其他人指出的那样，确保对于每个新的/malloc调用，都有一个后续的delete/free调用。
如果使用gcc，则有gprof可用。
我想知道程序员如何发现内存泄漏
有些人使用工具，有些人做你做的事情，也可以通过同行代码审查
是否应该遵循某种标准或过程来确保程序中没有内存泄漏
对我来说:每当我创建动态分配对象时，我总是把释放代码放在后面，然后在中间填充代码。如果您确定之间的代码中不会出现异常，那么这样做是可以的。否则，我会使用try-finally(我不经常使用c++)。
Valgrind http://valgrind.org/
and
广东发展银行 http://www.gnu.org/software/gdb/
AddressSanitizer (ASan)是一种快速的内存错误检测器。 它可以发现C/ c++程序中的use-after-free和{heap,stack,global}-buffer溢出错误。它发现:
在free之后使用(悬空指针解引用) 堆缓冲区溢出 堆栈缓冲区溢出 全局缓冲区溢出 退货后使用 初始化顺序错误
这个工具很快。仪器程序的平均速度为~2倍。
您可以在代码中使用一些技术来检测内存泄漏。最常见和最简单的检测方法是，定义一个宏(比如DEBUG_NEW)，并使用它与预定义的宏(如__FILE__和__LINE__)一起定位代码中的内存泄漏。这些预定义的宏告诉您内存泄漏的文件号和行号。
DEBUG_NEW只是一个宏，通常定义为:
#define DEBUG_NEW new(__FILE__, __LINE__)
#define new DEBUG_NEW
因此，无论在哪里使用new，它都可以跟踪文件和行号，这可以用来定位程序中的内存泄漏。
而__FILE__， __LINE__是预定义的宏，它们分别计算你使用它们的文件名和行号!
阅读下面的文章，它解释了使用DEBUG_NEW和其他有趣的宏的技术，非常漂亮:
一个跨平台的内存泄漏检测器
从Wikpedia,
Debug_new refers to a technique in C++ to overload and/or redefine operator new and operator delete in order to intercept the memory allocation and deallocation calls, and thus debug a program for memory usage. It often involves defining a macro named DEBUG_NEW, and makes new become something like new(_FILE_, _LINE_) to record the file/line information on allocation. Microsoft Visual C++ uses this technique in its Microsoft Foundation Classes. There are some ways to extend this method to avoid using macro redefinition while still able to display the file/line information on some platforms. There are many inherent limitations to this method. It applies only to C++, and cannot catch memory leaks by C functions like malloc. However, it can be very simple to use and also very fast, when compared to some more complete memory debugger solutions.
