#ifdef _DEBUG

#define new DEBUG_NEW

#undef THIS_FILE

static char THIS_FILE[] = __FILE__;

#endif

由于項(xiàng)目中的文件較多，如果到一個(gè)一個(gè)文件中去找，那是件枯燥而且乏味的工作， 而且難保不會(huì)有遺漏。所以我編寫(xiě)了腳本來(lái)報(bào)告沒(méi)有這幾句的文件。

         通過(guò)在文件中加上了上述的宏，我再次重新運(yùn)行剛才產(chǎn)生內(nèi)存泄漏的測(cè)試用例。這次我定位了泄漏的內(nèi)存分配語(yǔ)句。所以為了調(diào)試上的方便，我們應(yīng)保證文件中有如上的宏。找到了相關(guān)的分配語(yǔ)句就離解決這個(gè)錯(cuò)誤近了，現(xiàn)在就是要找出遺漏的釋放點(diǎn)。

         為了使用我以前安裝的共享版內(nèi)存泄漏檢測(cè)工具，我將系統(tǒng)的時(shí)間改成6月份。可惜還是提示過(guò)了試用期不讓使用，所以還得靠自己。通過(guò)查閱代碼，找出了幾個(gè)可疑點(diǎn)，分別加上了恰當(dāng)?shù)恼Z(yǔ)句，按一下build 后，剛巧有事就離開(kāi)了。回來(lái)后發(fā)現(xiàn)看看沒(méi)有編譯錯(cuò)誤，于是再測(cè)試用例，結(jié)果還是出現(xiàn)泄漏。于是我加上調(diào)試斷點(diǎn)來(lái)分析，可是程序根本不在斷點(diǎn)處停止。這讓我著實(shí)驚訝，難道程序并不經(jīng)過(guò)這些斷點(diǎn)？ 再放置幾個(gè)斷點(diǎn)，依然不停住，最后就在InitInstance()函數(shù)中放一斷點(diǎn)，可還是不停住。這時(shí)我才恍然大悟這個(gè)exe文件與代碼不一致。于是改回系統(tǒng)時(shí)間，重新build。再次運(yùn)行，程序在斷點(diǎn)處停住，運(yùn)行相應(yīng)的測(cè)試用例，也不再有內(nèi)存泄漏。

         在這個(gè)過(guò)程中，由于visual studio的編譯行為所采用的時(shí)間比較來(lái)決定編譯的行為及本人的粗心讓我浪費(fèi)了一些時(shí)間和精力。這也提示我們?cè)谠O(shè)計(jì)軟件時(shí)，對(duì)于優(yōu)化行為應(yīng)多加考慮，行為的優(yōu)化是否符合了用戶的企圖，如果與用戶的動(dòng)作不符合，則應(yīng)給用戶提示并得到用戶的指示。