一Debug 和 Release 編譯方式的本質區別
Debug 通常稱為調試版本它包含調試信息並且不作任何優化便於程序員調試程序Release 稱為發布版本它往往是進行了各種優化使得程序在代碼大小和運行速度上都是最優的以便用戶很好地使用
Debug 和 Release 的真正秘密在於一組編譯選項下面列出了分別針對二者的選項（當然除此之外還有其他一些如/Fd /Fo但區別並不重要通常他們也不會引起 Release 版錯誤在此不討論）
Debug 版本
/MDd /MLd 或 /MTd 使用 Debug runtime library（調試版本的運行時刻函數庫）
/Od 關閉優化開關
/D _DEBUG 相當於 #define _DEBUG打開編譯調試代碼開關（主要針對
assert函數）
/ZI 創建 Edit and continue（編輯繼續）數據庫這樣在調試過
程中如果修改了源代碼不需重新編譯
/GZ 可以幫助捕獲內存錯誤
/Gm 打開最小化重鏈接開關減少鏈接時間
Release 版本
/MD /ML 或 /MT 使用發布版本的運行時刻函數庫
/O 或 /O 優化開關使程序最小或最快
/D NDEBUG 關閉條件編譯調試代碼開關（即不編譯assert函數）
/GF 合並重復的字符串並將字符串常量放到只讀內存防止
被修改
實際上Debug 和 Release 並沒有本質的界限他們只是一組編譯選項的集合編譯器只是按照預定的選項行動事實上我們甚至可以修改這些選項從而得到優化過的調試版本或是帶跟蹤語句的發布版本
二哪些情況下 Release 版會出錯
有了上面的介紹我們再來逐個對照這些選項看看 Release 版錯誤是怎樣產生的
Runtime Library鏈接哪種運行時刻函數庫通常只對程序的性能產生影響調試版本的 Runtime Library 包含了調試信息並采用了一些保護機制以幫助發現錯誤因此性能不如發布版本編譯器提供的 Runtime Library 通常很穩定不會造成 Release 版錯誤倒是由於 Debug 的 Runtime Library 加強了對錯誤的檢測如堆內存分配有時會出現 Debug 有錯但 Release 正常的現象應當指出的是如果 Debug 有錯即使 Release 正常程序肯定是有 Bug 的只不過可能是 Release 版的某次運行沒有表現出來而已
優化這是造成錯誤的主要原因因為關閉優化時源程序基本上是直接翻譯的而打開優化後編譯器會作出一系列假設這類錯誤主要有以下幾種
（） 幀指針（Frame Pointer）省略（簡稱 FPO ）在函數調用過程中所有調用信息（返回地址參數）以及自動變量都是放在棧中的若函數的聲明與實現不同（參數返回值調用方式）就會產生錯誤 ————但 Debug 方式下棧的訪問通過 EBP 寄存器保存的地址實現如果沒有發生數組越界之類的錯誤（或是越界不多）函數通常能正常執行Release 方式下優化會省略 EBP 棧基址指針這樣通過一個全局指針訪問棧就會造成返回地址錯誤是程序崩潰C++ 的強類型特性能檢查出大多數這樣的錯誤但如果用了強制類型轉換就不行了你可以在 Release 版本中強制加入 /Oy 編譯選項來關掉幀指針省略以確定是否此類錯誤此類錯誤通常有
● MFC 消息響應函數書寫錯誤正確的應為
afx_msg LRESULT OnMessageOwn（WPARAM wparam LPARAM lparam）
ON_MESSAGE 宏包含強制類型轉換防止這種錯誤的方法之一是重定義 ON_MESSAGE 宏把下列代碼加到 stdafxh 中（在#include afxwinh之後）函數原形錯誤時編譯會報錯
#undef ON_MESSAGE
#define ON_MESSAGE（message memberFxn） { message AfxSig_lwl （AFX_PMSG）（AFX_PMSGW）（static_cast< LRESULT （AFX_MSG_CALL CWnd*）（WPARAM LPARAM） > （&memberFxn） }
（） volatile 型變量volatile 告訴編譯器該變量可能被程序之外的未知方式修改（如系統其他進程和線程）優化程序為了使程序性能提高常把一些變量放在寄存器中（類似於 register 關鍵字）而其他進程只能對該變量所在的內存進行修改而寄存器中的值沒變如果你的程序是多線程的或者你發現某個變量的值與預期的不符而你確信已正確的設置了則很可能遇到這樣的問題這種錯誤有時會表現為程序在最快優化出錯而最小優化正常把你認為可疑的變量加上 volatile 試試
（） 變量優化優化程序會根據變量的使用情況優化變量例如函數中有一個未被使用的變量在 Debug 版中它有可能掩蓋一個數組越界而在 Release 版中這個變量很可能被優化調此時數組越界會破壞棧中有用的數據當然實際的情況會比這復雜得多與此有關的錯誤有
● 非法訪問包括數組越界指針錯誤等例如
void fn(void)
{
int i;
i = ;
int a[];
{
int j;
j = ;
}
a[] = ;//當然錯誤不會這麼明顯例如下標是變量
a[] = ;
}
j 雖然在數組越界時已出了作用域但其空間並未收回因而 i 和 j 就會掩蓋越界而 Release 版由於 ij 並未其很大作用可能會被優化掉從而使棧被破壞
_DEBUG 與 NDEBUG 當定義了 _DEBUG 時assert（） 函數會被編譯而 NDEBUG 時不被編譯除此之外VC++中還有一系列斷言宏這包括
ANSI C 斷言 void assert(int expression );
C Runtime Lib 斷言 _ASSERT( booleanExpression );
_ASSERTE( booleanExpression );
MFC 斷言 ASSERT( booleanExpression );
VERIFY( booleanExpression );
ASSERT_VALID( pObject );
ASSERT_KINDOF( classname pobject );
ATL 斷言 ATLASSERT( booleanExpression );
此外TRACE（） 宏的編譯也受 _DEBUG 控制
所有這些斷言都只在 Debug版中才被編譯而在 Release 版中被忽略唯一的例外是 VERIFY（） 事實上這些宏都是調用了 assert（） 函數只不過附加了一些與庫有關的調試代碼如果你在這些宏中加入了任何程序代碼而不只是布爾表達式（例如賦值能改變變量值的函數調用 等）那麼 Release 版都不會執行這些操作從而造成錯誤初學者很容易犯這類錯誤查找的方法也很簡單因為這些宏都已在上面列出只要利用 VC++ 的 Find in Files 功能在工程所有文件中找到用這些宏的地方再一一檢查即可另外有些高手可能還會加入 #ifdef _DEBUG 之類的條件編譯也要注意一下
順便值得一提的是 VERIFY（） 宏這個宏允許你將程序代碼放在布爾表達式裡這個宏通常用來檢查 Windows API 的返回值有些人可能為這個原因而濫用 VERIFY（） 事實上這是危險的因為 VERIFY（） 違反了斷言的思想不能使程序代碼和調試代碼完全分離最終可能會帶來很多麻煩因此專家們建議盡量少用這個宏
/GZ 選項這個選項會做以下這些事
（） 初始化內存和變量包括用 xCC 初始化所有自動變量xCD （ Cleared Data ） 初始化堆中分配的內存（即動態分配的內存例如 new ）xDD （ Dead Data ） 填充已被釋放的堆內存（例如 delete ）xFD（ deFencde Data ） 初始化受保護的內存（debug 版在動態分配內存的前後加入保護內存以防止越界訪問）其中括號中的詞是微軟建議的助記詞這樣做的好處是這些值都很大作為指針是不可能的（而且 位系統中指針很少是奇數值在有些系統中奇數的指針會產生運行時錯誤）作為數值也很少遇到而且這些值也很容易辨認因此這很有利於在 Debug 版中發現 Release 版才會遇到的錯誤要特別注意的是很多人認為編譯器會用 來初始化變量這是錯誤的（而且這樣很不利於查找錯誤）
（） 通過函數指針調用函數時會通過檢查棧指針驗證函數調用的匹配性（防止原形不匹配）
（） 函數返回前檢查棧指針確認未被修改（防止越界訪問和原形不匹配與第二項合在一起可大致模擬幀指針省略 FPO ）
通常 /GZ 選項會造成 Debug 版出錯而 Release 版正常的現象因為 Release 版中未初始化的變量是隨機的這有可能使指針指向一個有效地址而掩蓋了非法訪問
除此之外/Gm /GF 等選項造成錯誤的情況比較少而且他們的效果顯而易見比較容易發現
From:http://tw.wingwit.com/Article/program/net/201311/11874.html
