VC++中本身就有內存泄漏檢查的機制,可以在嚮導生成的支持MFC的工程中看到如下代碼:
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
先具體解釋一下：
#ifdef _DEBUG //如果有定義_DEBUG
#define new DEBUG_NEW //將new宏定義成DEBUG_NEW，
那麼則是代碼中有new的都換成DEBUG_NEW。
#undef THIS_FILE//取消THIS_FILE的宏定義
static char THIS_FILE[] = __FILE__;//將THIS_FILE
定義成一個數組，該數組用static聲名，則只能在該文件內訪問。__FILE__是gcc定義的一個擴展宏，代表的該文件的文件名。
#endif//這個不用說了吧
有了這樣的宏定義，在編譯DEBUG版時，出現在這個cpp文件中的所有new都被替換成DEBUG_NEW了。那麼DEBUG_NEW是什麼呢？DEBUG_NEW也是一個宏，以下摘自afx.h，1632行
#define DEBUG_NEW new(THIS_FILE, __LINE__)
所以如果有這樣一行代碼：
char* p = new char[200];
經過宏替換就變成了：
char* p = new( THIS_FILE, __LINE__)char[200];
根據C++的標準，對於以上的new的使用方法，編譯器會去找這樣定義的operator new：
void* operator new(size_t, LPCSTR, int)
我們在afxmem.cpp 63行找到了一個這樣的operator new 的實現
void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine)
{
return ::operator new(nSize, _NORMAL_BLOCK, lpszFileName, nLine);
}
void* __cdecl operator new(size_t nSize, int nType, LPCSTR lpszFileName, int nLine)
{
…
pResult = _malloc_dbg(nSize, nType, lpszFileName, nLine);
if (pResult != NULL)
return pResult;
…
}
第二個operator new函數比較長，爲了簡單期間，我只摘錄了部分。很顯然最後的內存分配還是通過_malloc_dbg函數實現的，這個函數屬於MS C-Runtime Library 的Debug Function。這個函數不但要求傳入內存的大小，另外還有文件名和行號兩個參數。文件名和行號就是用來記錄此次分配是由哪一段代碼造成的。如果這塊內存在程序結束之前沒有被釋放，那麼這些信息就會輸出到Debug窗口裏。
這裏順便提一下THIS_FILE，__FILE和__LINE__。__FILE__和__LINE__都是編譯器定義的宏。當碰到__FILE__時，編譯器會把__FILE__替換成一個字符串，這個字符串就是當前在編譯的文件的路徑名。當碰到__LINE__時，編譯器會把__LINE__替換成一個數字，這個數字就是當前這行代碼的行號。在DEBUG_NEW的定義中沒有直接使用__FILE__，而是用了THIS_FILE，其目的是爲了減小目標文件的大小。假設在某個cpp文件中有100處使用了new，如果直接使用__FILE__，那編譯器會產生100個常量字符串，這100個字符串都是這個cpp文件的路徑名，顯然十分冗餘。如果使用THIS_FILE，編譯器只會產生一個常量字符串，那100處new的調用使用的都是指向常量字符串的指針。
再次觀察一下由MFC Application Wizard生成的項目，我們會發現在cpp文件中只對new做了映射，如果你在程序中直接使用malloc函數分配內存，調用malloc的文件名和行號是不會被記錄下來的。如果這塊內存發生了泄漏，MS C-Runtime Library仍然能檢測到，但是當輸出這塊內存塊的信息，不會包含分配它的的文件名和行號。
要在非MFC程序中打開內存泄漏的檢測功能非常容易，你只要在程序的入口處加入以下幾行代碼：
int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );
tmpFlag |= _CRTDBG_LEAK_CHECK_DF;
_CrtSetDbgFlag( tmpFlag );
這樣，在程序結束的時候，也就是winmain，main或dllmain函數返回之後，如果還有內存塊沒有釋放，它們的信息會被打印到Debug窗口裏。
如果你試着創建了一個非MFC應用程序，而且在程序的入口處加入了以上代碼，並且故意在程序中不釋放某些內存塊，你會在Debug窗口裏看到以下的信息：
{47} normal block at 0x00C91C90, 200 bytes long.
Data: < > 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
內存泄漏的確檢測到了，但是和上面MFC程序的例子相比，缺少了文件名和行號。對於一個比較大的程序，沒有這些信息，解決問題將變得十分困難。
爲了能夠知道泄漏的內存塊是在哪裏分配的，你需要實現類似MFC的映射功能，把new，maolloc等函數映射到_malloc_dbg函數上。這裏我不再贅述，你可以參考MFC的源代碼。
由於Debug Function實現在MS C-RuntimeLibrary中，所以它只能檢測到堆內存的泄漏，而且只限於malloc，realloc或strdup等分配的內存，而那些系統資源，比如HANDLE，GDI Object，或是不通過C-Runtime Library分配的內存，比如VARIANT，BSTR的泄漏，它是無法檢測到的，這是這種檢測法的一個重大的侷限性。另外，爲了能記錄內存塊是在哪裏分配的，源代碼必須相應的配合，這在調試一些老的程序非常麻煩，畢竟修改源代碼不是一件省心的事，這是這種檢測法的另一個侷限性。