VC中debug和release版本的區別

vc中debug和release的不同 收藏 
在使用VC開發軟體的過程中，正當要享受那種興奮的時候突然發現：release與debug執行結果不一致，甚至出錯，而release又不方便除錯，真的是當頭一棒啊，可是疼歸疼，問題總要解決，下面將講述一下我的幾點經驗，看看是不是其中之一：

1. 變數。
大家都知道，debug跟release在初始化變數時所做的操作是不同的，debug是將每個位元組位都賦成0xcc(注1)，而release的賦值近似於隨機(我想是直接從記憶體中分配的，沒有初始化過)。這樣就明確了，如果你的程式中的某個變數沒被初始化就被引用，就很有可能出現異常：用作控制變數將導致流程導向不一致；用作陣列下標將會使程式崩潰；更加可能是造成其他變數的不準確而引起其他的錯誤。所以在宣告變數後馬上對其初始化一個預設的值是最簡單有效的辦法，否則專案大了你找都沒地方找。程式碼存在錯誤在debug方式下可能會忽略而不被察覺到，如debug方式下陣列越界也大多不會出錯，在release中就暴露出來了，這個找起來就比較難了:( 還是自己多加註意吧

2. 自定義訊息的訊息引數。
MFC為我們提供了很好的訊息機制，更增加了自定義訊息，好處我就不用多說了。這也存在debug跟release的問題嗎？答案是肯定的。在自定義訊息的函式體宣告時，時常會看到這樣的寫法：afx_msg LRESULT OnMessageOwn(); Debug情況下一般不會有任何問題，而當你在Release下且多執行緒或程式間使用了訊息傳遞時就會導致無效控制程式碼之類的錯誤。導致這個錯誤直接原因是訊息體的引數沒有新增，即應該寫成：afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam); (注2)

3. release模式下不出錯，但debug模式下報錯。
這種情況下大多也是因為程式碼書寫不正確引起的，檢視MFC的原始碼，可以發現好多ASSERT的語句(斷言)，這個巨集只是在debug模式下才有效，那麼就清楚了，release版不報錯是忽略了錯誤而不是沒有錯誤，這可能存在很大的隱患，因為是Debug模式下，比較方便除錯，好好的檢查自己的程式碼，再此就不多說了。

4. ASSERT, VERIFY, TRACE..........除錯巨集
這種情況很容易解釋。舉個例子：請在VC下輸入ASSERT然後選中按F12跳到巨集定義的地方，這裡你就能夠發現Debug中ASSERT要執行AfxAssertFailedLine，而Release下的巨集定義卻為"#define ASSERT(f) ((void)0)"。所以注意在這些除錯巨集的語句不要用程式相關變數如i++寫操作的語句。VERIFY是個例外，"#define VERIFY(f) ((void)(f))"，即執行，這裡的作用就不多追究了，有興趣可自己研究:)。

總結：
Debug與Release不同的問題在剛開始編寫程式碼時會經常發生，99%是因為你的程式碼書寫錯誤而導致的，所以不要動不動就說系統問題或編譯器問題，努力找找自己的原因才是根本。我從前就常常遇到這情況，經歷過一次次的教訓後我就開始注意了，現在我所寫過的程式碼我已經好久沒遇到這種問題了。下面是幾個避免的方面，即使沒有這種問題也應注意一下：

1. 注意變數的初始化，尤其是指標變數，陣列變數的初始化(很大的情況下另作考慮了)。
2. 自定義訊息及其他宣告的標準寫法
3. 使用除錯巨集時使用後最好註釋掉
4. 儘量使用try - catch(...)

5. 儘量使用模組，不但表達清楚而且方便除錯。

關於 Debug 和 Release 版本區別

 

關於Debug和Release之本質區別的討論本文主要包含如下內容：
1. Debug 和 Release 編譯方式的本質區別
2. 哪些情況下 Release 版會出錯
2. 怎樣“除錯” Release 版的程式

一、Debug 和 Release 編譯方式的本質區別
Debug 通常稱為除錯版本，它包含除錯資訊，並且不作任何優化，便於程式設計師除錯程
序。Release 稱為釋出版本，它往往是進行了各種優化，使得程式在程式碼大小和執行速度
上都是最優的，以便使用者很好地使用。
Debug 和 Release 的真正祕密，在於一組編譯選項。下面列出了分別針對二者的選項
（當然除此之外還有其他一些，如/Fd /Fo，但區別並不重要，通常他們也不會引起 Rele
ase 版錯誤，在此不討論）

Debug 版本：
/MDd /MLd 或 /MTd 使用 Debug runtime library(除錯版本的執行時刻函式庫)
/Od 關閉優化開關
/D "_DEBUG" 相當於 #define _DEBUG,開啟編譯除錯程式碼開關(主要針對
assert函式)
/ZI 建立 Edit and continue(編輯繼續)資料庫，這樣在除錯過
程中如果修改了原始碼不需重新編譯
/GZ 可以幫助捕獲記憶體錯誤
/Gm 開啟最小化重連結開關，減少連結時間

Release 版本：
/MD /ML 或 /MT 使用釋出版本的執行時刻函式庫
/O1 或 /O2 優化開關，使程式最小或最快
/D "NDEBUG" 關閉條件編譯除錯程式碼開關(即不編譯assert函式)
/GF 合併重複的字串，並將字串常量放到只讀記憶體，防止
被修改
實際上，Debug 和 Release 並沒有本質的界限，他們只是一組編譯選項的集合，編譯
器只是按照預定的選項行動。事實上，我們甚至可以修改這些選項，從而得到優化過的調
試版本或是帶跟蹤語句的釋出版本。

二、哪些情況下 Release 版會出錯

有了上面的介紹，我們再來逐個對照這些選項看看 Release 版錯誤是怎樣產生的

1. Runtime Library：

2. 優化：這類錯誤主要有以下幾種：

(1) 幀指標(Frame Pointer)省略（簡稱 FPO ）：在函式呼叫過程中，所有呼叫資訊
（返回地址、引數）以及自動變數都是放在棧中的。若函式的宣告與實現不同（引數、返
回值、呼叫方式），就會產生錯誤————但 Debug 方式下，棧的訪問通過 EBP 暫存器
儲存的地址實現，如果沒有發生陣列越界之類的錯誤（或是越界“不多”），函式通常能
正常執行；Release 方式下，優化會省略 EBP 棧基址指標，這樣通過一個全域性指標訪問棧
就會造成返回地址錯誤是程式崩潰。C++ 的強型別特效能檢查出大多數這樣的錯誤，但如
果用了強制型別轉換，就不行了。你可以在 Release 版本中強制加入 /Oy- 編譯選項來關
掉幀指標省略，以確定是否此類錯誤。
(2) volatile 型變數：volatile 告訴編譯器該變數可能被程式之外的未知方式修改
（如系統、其他程式和執行緒）。

(3) 變數優化：優化程式會根據變數的使用情況優化變數。例如，函式中有一個未被
使用的變數，在 Debug 版中它有可能掩蓋一個陣列越界，而在 Release 版中，這個變數
很可能被優化調，此時陣列越界會破壞棧中有用的資料。當然，實際的情況會比這複雜得
多。與此有關的錯誤有：

3. _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 控制。

4. /GZ 選項：這個選項會做以下這些事

(1) 初始化記憶體和變數。
(2) 通過函式指標呼叫函式時，會通過檢查棧指標驗證函式呼叫的匹配性。（防止原
形不匹配）
(3) 函式返回前檢查棧指標，確認未被修改.

三、怎樣“除錯” Release 版的程式

1. 前面已經提過，Debug 和 Release 只是一組編譯選項的差別，實際上並沒有什麼
定義能區分二者。我們可以修改 Release 版的編譯選項來縮小錯誤範圍。如上所述，可以
把 Release 的選項逐個改為與之相對的 Debug 選項，如 /MD 改為 /MDd、/O1 改為 /Od
，或執行時間優化改為程式大小優化。注意，一次只改一個選項，看改哪個選項時錯誤消
失，再對應該選項相關的錯誤，針對性地查詢。這些選項在 Project\Settings... 中都可
以直接通過列表選取，通常不要手動修改。由於以上的分析已相當全面，這個方法是最有
效的。
2.你也可以像 Debug 一樣除錯你的 Release 版，只要加入除錯符號。在 Project/S
ettings... 中，選中 Settings for "Win32 Release"，選中 C/C++ 標籤，Category 選
General，Debug Info 選 Program Database。再在 Link 標籤 Project options 最後
加上 "/OPT:REF" (引號不要輸)。

 

I.        記憶體分配問題

1.          變數未初始化。下面的程式在debug中執行的很好。

      thing * search(thing * something)
        BOOL found;
        for(int i = 0; i < whatever.GetSize(); i++)
          {
          if(whatever[i]->field == something->field)
            { /* found it */
              found = TRUE;
              break;
            } /* found it */
          }
    if(found)
            return whatever[i];
    else
            return NULL;
而在release中卻不行，因為debug中會自動給變數初始化found=FALSE,而在release版中則不會。所以儘可能的給變數、類或結構初始化。

2.            資料溢位的問題

        如：char buffer[10];
            int counter;

      lstrcpy(buffer, "abcdefghik");

在debug 版中buffer的NULL覆蓋了counter的高位，但是除非counter>16M,什麼問題也沒有。但是在release版中， counter可能被放在暫存器中，這樣NULL就覆蓋了buffer下面的空間，可能就是函式的返回地址，這將導致ACCESS ERROR。

3.        DEBUG版和RELEASE版的記憶體分配方式是不同的 。如果你在DEBUG版中申請  ele 為 6*sizeof(DWORD)=24bytes,實際上分配給你的是32bytes（debug版以32bytes為單位分配），而在release版，分配給你的就是24bytes（release版以8bytes為單位），所以在debug版中如果你寫ele[6],可能不會有什麼問題，而在release版中，就有ACCESS VIOLATE。

II.      ASSERT和VERIFY

1.        ASSERT在Release版本中是不會被編譯的。

ASSERT巨集是這樣定義的

        #ifdef _DEBUG
        #define ASSERT(x) if( (x) == 0) report_assert_failure()
        #else
        #define ASSERT(x)
        #endif
        實際上覆雜一些，但無關緊要。假如你在這些語句中加了程式中必須要有的程式碼
比如

ASSERT(pNewObj = new CMyClass);

pNewObj->MyFunction();

這種時候Release版本中的pNewObj不會分配到空間

所以執行到下一個語句的時候程式會報該程式執行了非法操作的錯誤。這時可以用VERIFY ：

        #ifdef _DEBUG
        #define VERIFY(x) if( (x) == 0) report_assert_failure()
    #else
        #define VERIFY(x) (x)
        #endif
這樣的話，程式碼在release版中就可以執行了。

III.  引數問題：

自定義訊息的處理函式，必須定義如下：

afx_msg LRESULT OnMyMessage(WPARAM, LPARAM);

返回值必須是HRESULT型，否則Debug會過，而Release出錯

IV.  記憶體分配

保證資料建立和清除的統一性：如果一個DLL提供一個能夠建立資料的函式，那麼這個DLL同時應該提供一個函式銷燬這些資料。資料的建立和清除應該在同一個層次上。

V.    DLL的災難

人們將不同版本DLL混合造成的不一致性形象的稱為 “動態連線庫的地獄“(DLL Hell) ，甚至微軟自己也這麼說(http://msdn.microsoft.com/library/techart/dlldanger1.htm)。

      如果你的程式使用你自己的DLL時請注意：

1.      不能將debug和release版的DLL混合在一起使用。debug都是debug版，release版都是release版。

解決辦法是將debug和release的程式分別放在主程式的debug和release目錄下

2.        千萬不要以為靜態連線庫會解決問題，那隻會使情況更糟糕。

VI.  RELEASE板中的除錯 ：

1.        將ASSERT() 改為 VERIFY() 。找出定義在"#ifdef _DEBUG"中的程式碼，如果在RELEASE版本中需要這些程式碼請將他們移到定義外。查詢TRACE(...)中程式碼，因為這些程式碼在RELEASE中也不被編譯。 請認真檢查那些在RELEASE中需要的程式碼是否並沒有被便宜。

2.        變數的初始化所帶來的不同，在不同的系統，或是在DEBUG/RELEASE版本間都存在這樣的差異，所以請對變數進行初始化。

3.        是否在編譯時已經有了警告?請將警告級別設定為3或4,然後保證在編譯時沒有警告出現.

VII.  將Project Settings" 中 "C++/C " 專案下優化選項改為Disbale（Debug）。編譯器的優化可能導致許多意想不到的錯誤，請參考http://www.pgh.net/~newcomer/debug_release.htm

1.        此外對RELEASE版本的軟體也可以進行除錯，請做如下改動：

在"Project Settings" 中 "C++/C " 專案下設定 "category" 為 "General" 並且將"Debug Info"設定為 "Program Database"。

在"Link"專案下選中"Generate Debug Info"檢查框。

"Rebuild All"

如此做法會產生的一些限制：

無法獲得在MFC DLL中的變數的值。

必須對該軟體所使用的所有DLL工程都進行改動。

另：

MS BUG：MS的一份技術文件中表明，在VC5中對於DLL的"Maximize Speed"優化選項並未被完全支援，因此這將會引起記憶體錯誤並導致程式崩潰。

2.        www.sysinternals.com有一個程式DebugView，用來捕捉OutputDebugString的輸出，執行起來後（估計是自設為system debugger）就可以觀看所有程式的OutputDebugString的輸出。此後，你可以脫離VC來執行你的程式並觀看除錯資訊。

3.        有一個叫Gimpel Lint的靜態程式碼檢查工具，據說比較好用。http://www.gimpel.com 不過要化$的。

參考文獻：

1)        http://www.cygnus-software.com/papers/release_debugging.html

2)        http://www.pgh.net/~newcomer/debug_release.htm

 

在VC 中當整個工程較大時，軟體時常為出現在DEBUG狀態下能執行而在RELEASE狀態下無法執行的情況。由於開發者通常在DEBUG狀態下開發軟體，所以這種情況時常是在我們辛苦工作一兩個月後，滿懷信心的準備將軟體發行時發生。為了避免無謂的損失，我們最好進行以下的檢查:

1、時常測試軟體的兩種版本。

2、不要輕易將問題歸結為DEBUG/RELEASE問題，除非你已經充分對兩種版本進行了測試。

3、預處理的不同，也有可能引起這樣的問題。
出現問題的一種可能性是在不同版本的編譯間定義了不同的預處理標記。請對你的DEBUG版本的軟體試一下以下改動：

在"Project Setting(ALT-F7)" 中的C/C++項中設定目錄(category)為"General"，並且改動"_DEBUG"定義為"NDEBUG".
設定目錄為"Preprocessor"並且新增定義"_DEBUG到"Undefined Symbols"輸入框.
選擇Rebuild ALL,重新編譯.
如果經過編譯的程式產生了問題，請對程式碼進行如下改動：
將ASSERT() 改為 VERIFY()。因為ASSERT中的內容在Release版本中不被編譯。
找出定義在"#ifdef _DEBUG"中的程式碼，如果在RELEASE版本中需要這些程式碼請將他們移到定義外。
查詢TRACE(...)中程式碼，因為這些程式碼在RELEASE中也不被編譯。
所以請認真檢查那些在RELEASE中需要的程式碼是否並沒有被編譯。

4、變數的初始化所帶來的不同，在不同的系統，或是在DEBUG/RELEASE版本間都存在這樣的差異，所以請對變數進行初始化。

5、是否在編譯時已經有了警告?請將警告級別設定為3或4,然後保證在編譯時沒有警告出現.

6、是否改動了資原始檔.

7、此外對RELEASE版本的軟體也可以進行除錯，請做如下改動：

在"Project Settings" 中 "C++/C " 專案下設定 "category" 為 "General" 並且將"Debug Info"設定為 "Program Database".
在"Link"專案下選中"Generate Debug Info"檢查框。
"Rebuild All"
如此做法會產生的一些限制：
無法獲得在MFC DLL中的變數的值。
必須對該軟體所使用的所有DLL工程都進行改動。

另：
MS BUG：MS的一份技術文件中表明，在VC5中對於DLL的"Maximize Speed"優化選項並未被完全支援，因此這將會引起記憶體錯誤並導致程式崩潰。

VC++中debug跟release編譯模式的區別總結

根據網路上的文章總結，以備查詢，:) 

Debug與Release版本的區別 

    Debug 和 Release 並沒有本質的區別，他們只是VC預定義提供的兩組編譯選項的集合，編譯器只是按照預定的選項行動。如果我們願意，我們完全可以把Debug和Release的行為完全顛倒過來。當然也可以提供其他的模式，例如自己定義一組編譯選項，然後命名為MY_ABC等。習慣上，我們仍然更願意使用VC已經定義好的名稱。 
    Debug版本包括除錯資訊，所以要比Release版本大很多（可能大數百K至數M）。至於是否需要DLL支援，主要看你採用的編譯選項。如果是基於 ATL的，則Debug和Release版本對DLL的要求差不多。如果採用的編譯選項為使用MFC動態庫，則需要MFC42D.DLL等庫支援，而 Release版本需要MFC42.DLL支援。Release不對原始碼進行除錯，不考慮MFC的診斷巨集，使用的是 MFC  Release庫，編譯時對應用程式的速度進行優化，而Debug則正好相反，它允許對原始碼進行除錯，可以定義和使用MFC的 診斷巨集，採用MFC  Debug庫，對速度沒有優化。    
    既然Debug和 Release僅僅是編譯選項的不同，那麼為什麼要區分Debug和Release版本呢？ 
    Debug和Release，在我看來主要是針對其面 向的目標不同的而進行區分的。Debug通常稱為除錯版本，通過一系列編譯選項的配合，編譯的結果通常包含除錯資訊，而且不做任何優化，以為開發 人員提供強大的應用程式除錯能力。而Release通常稱為釋出版本，是為使用者使用的，一般客戶不允許在釋出版本上進行除錯。所以不儲存除錯信 息，同時，它往往進行了各種優化，以期達到程式碼最小和速度最優。為使用者的使用提供便利。 

    下面僅就預設的Debug和Release版本的選項進行 比較，詳細的編譯選項可以看MSDN的說明。 
我們將預設的Debug和Release的選項設定進行比較，過濾掉相同設定，主要的不同如下： 
編譯選項：/Od /D "_DEBUG" /Gm /RTC1 /MDd /Fo"Debug““" /ZI 
連結選項：/OUT："D：“MyProject“logging“Debug“OptionTest.dll" /INCREMENTAL 
Release設定： 
編譯選項：/O2 /GL /D "NDEBUG" /FD /MD /Fo"Release““" /Zi 
鏈 接選項：/OUT："D：“MyProject“logging“Release“OptionTest.dll" /INCREMENTAL：NO 

Debug  版本：  
/MDd  /MLd  或  /MTd  使用  Debug  runtime  library(除錯版本的執行 時刻函式庫)  
/Od  關閉優化開關  
/D  "_DEBUG"  相當於  #define  _DEBUG,開啟編譯除錯程式碼 開關(主要針對assert函式)  
/ZI  建立  Edit  and  continue資料庫，在除錯 過程中如果修改了原始碼不需重新編譯  
/GZ  可以幫助捕獲記憶體錯誤  
/Gm  開啟最小化重連結開關，減少連結時 間  
Release  版本：    
/MD  /ML  或  /MT  使用釋出版本的執行時刻函式庫  
/O1  或  /O2  優 化開關，使程式最小或最快  
/D  "NDEBUG"  關閉條件編譯除錯程式碼開關(即不編譯assert函式)  
/GF  合併重 復的字串，並將字串常量放到只讀記憶體，防止被修改  

MDd與MD 
    首 先，Debug版本使用除錯版本的執行時庫（/MDd選項），Relase版本則使用的是釋出版本的執行時庫（vcrt.dll）。其區別主要在於執行時 的效能影響。除錯版本的執行時庫包含了除錯資訊，並採用了一些保護機制以幫助發現錯誤，也因此，其效能不如釋出版本。編譯器提供的Runtime Library很穩定，不會造成Release版本錯誤，倒是由於Debug版本的Runtime Library加強了對錯誤的檢測，如堆記憶體分配檢查等，反而會報告錯誤，應當指出，如果Debug有錯誤，而Release版本正常，程式肯定是有 Bug的，只是我們還沒有發現。 
ZI與Zi 
    其次，/ZI選項與/Zi選項。通過使用/ZI選項，可以在除錯過程修改程式碼 而不需要重新編譯。這是個除錯的好幫手，可如果我們使用Release版本，這將變得不可行。 

Od與O2 
/O2與/Od 選項：Od是關閉編譯器優化，普遍用於Debug版本。而O2選項是建立最快速程式碼，這當然是Release版本的不二選擇。 

RTCx選 項 
/RTCx選項讓編譯器插入動態檢測程式碼以幫助你檢測程式中的錯誤。比如，它會將區域性變數初始化為非零值。包括用 0xCC初始化所有自動變數，0xCD初始化堆中分配的記憶體（即new的記憶體），使用0xDD填充被釋放的記憶體（即delete的記憶體），0xFD初始化 受保護的記憶體（debug版在動態分配記憶體的前後加入保護記憶體以防止越界訪問）。這樣做的好處是這些值都很大，一般不可能作為指標，考試，大提示作為數值 也很少用到，而且這些值很容易辯認，因此有利於在Debug版本中發現Release版才會遇到的錯誤。另外，通過函式指標呼叫函式時，會通過檢 查棧指標驗證函式呼叫的匹配性（防止原型不匹配）。使用/RTCx選項會造成Debug版本出錯，而Release版本正常的現象，因為 Release版中未初始化的變數是隨機的，很可能使指標指向了有效但是錯誤的地址，從而掩蓋了錯誤。這個編譯選項只能在/Od選項下使用。 

Gm，INCREMENTAL or NO 
編譯選項中的Gm和連結選項中的 INCREMENTAL都只為一個目的，加快編譯速度。我們經常遇上這樣的問題，只修改了一個標頭檔案，結果卻造成所有動態庫的重新編譯。而這兩個選項就是 為了解決這樣的問題。如果啟用了/Gm開關，編譯器在專案中的.idb檔案中儲存了原始檔和類定義之間的依賴關係。之後的編譯過程中使用.idb 檔案中的資訊確定是否需要編譯某個原始檔，哪怕是此原始檔已經包含了已修改的.h檔案。 
INCREMENTAL開關預設是開啟的。使用增量連結生 成的可執行檔案或者動態連結庫會大於非增量連結的程式，因為有程式碼和資料的填充。另外，增量連結的檔案還包含跳轉trunk以處理函式重定位到新地址。 
MSDN 上明確指出：為確保最終釋出版本不包含填充或者trunk，請非增量連結程式。 

/GZ  選項：做以下這些事  
1.初 始化記憶體和變數。包括用  0xCC  初始化所有自動變數，0xCD  (  Cleared  Data  )  初始化堆中分配的記憶體（即動態分配 的記憶體，例如  new  ），0xDD  (  Dead  Data  )  填充已被釋放的堆記憶體（例 如  delete  ），0xFD(  deFencde  Data  )  初始化受保護的記憶體（debug  版在動態分配記憶體的前後加入保護內 存以防止越界訪問），其中括號中的詞是微軟建議的助記詞。這樣做的好處是這些值都很大，作為指標是不可能的（而且  32  位系統中指標很少是奇數值， 在有些系統中奇數的指標會產生執行時錯誤），作為數值也很少遇到，而且這些值也很容易辨認，因此這很有利於在  Debug  版中發 現  Release  版才會遇到的錯誤。要特別注意的是，很多人認為編譯器會用  0  來初始化變數，這是錯誤的（而且這樣很不利於查詢錯 誤）。  
2.   通過函式指標呼叫函式時，會通過檢查棧指標驗證函式呼叫的匹配性。（防止原形不匹配）  
3.   函式返回前檢查 棧指標，確認未被修改。（防止越界訪問和原形不匹配，與第二項合在一起可大致模擬幀指標省略  FPO  ）  

    通常  /GZ  選 項會造成  Debug  版出錯而  Release  版正常的現象，因為  Release  版中未初始化的變數是隨機的，這有可能使指標指向一 個有效地址而掩蓋了非法訪問。  

_DEBUG與NDEBUG 
這是最重要的一個選項。這兩個是編譯器的前處理器定義，預設情況下_DEBUG用於Debug版本，而NDEBUG用於Release版本。 它們可以說是重要的無以復加。因為，assert系列的斷言僅僅在_DEBUG下生效！ 
下面是assert.h檔案中摘出來的： 

可以看出在未定義_DEBUG時，assert變成一條空語句不被執行。 
也就是說，我們現在所有釋出的版本無法使 用斷言機制進行程式除錯。 

相關經驗： 
1. 變數。 
    大家都知道，debug跟release在初始化變數時所做的操作是不同的，debug是將每個位元組位都賦成0xcc， 而release的賦值近似於隨機。如果你的程式中的某個變數沒被初始化就被引用，就很有可能出現異常：用作控制變數將導致流程導向不一致；用作陣列下標將會使程式崩潰；更加可能是造成其他變數的不準確而引起其他的錯誤。所以在宣告變數後馬上對其 初始化一個預設的值是最簡單有效的辦法，否則專案大了你找都沒地方找。程式碼存在錯誤在debug方式下可能會忽略而不被察覺到。debug方式下陣列越界也大多不會出錯，在release中就暴露出來了，這個找起來就比較難了。 
2. 自定義訊息的訊息引數。 
   MFC為我們提供了很好的訊息機制，更增加了自定義訊息，好處我就不用多說了。這也存在debug跟release的問 題嗎？答案是肯定的。在自定義訊息的函式體宣告時，時常會看到這樣的寫法：afx_msg LRESULT OnMessageOwn(); Debug 情況下一般不會有任何問題，而當你在Release下且多執行緒或程式間使用了訊息傳遞時就會導致無效控制程式碼之類的錯誤。導致這個錯誤直接原因是訊息體的引數 沒有新增，即應該寫 成：afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam); 3. release模式下不出錯，但debug模式下報錯。 
    這種情況下大多也是因為程式碼書寫不正確引起的，檢視MFC 的原始碼，可以發現好多ASSERT的語句(斷言)，這個巨集只是在debug模式下才有效，那麼就清楚了，release版不報錯是忽略了錯誤而不是沒有錯誤，這可能存在很大的隱患，因為是Debug模式下，比較方便除錯，好好的檢查自己的程式碼，再此就不多說了。 
3. ASSERT, VERIFY, TRACE.......... 除錯巨集 
    這種情況很容易解釋。舉個例子：請在VC下輸入ASSERT然後選中按F12跳到巨集定義的地方，這裡你就能夠發現Debug中 ASSERT要執行AfxAssertFailedLine，而Release下的巨集定義卻為\"#define ASSERT(f) ((void)0)\"。所以注意在這些除錯巨集的語句不要用程式相關變數如i++寫操作的語句。 
VERIFY 是個例外，\"#define VERIFY(f) ((void)(f))\"，即執行。 

哪些情況下Release版會出錯？  
1.  Runtime  Library：連結哪種執行時刻函式庫通常只對程式的效能產生影響。除錯版本 的  Runtime  Library  包含了除錯資訊，並採用了一些保護機制以幫助發現錯誤，因此效能不如釋出版本。編譯器提供 的  Runtime  Library  通常很穩定，不會造成  Release  版錯誤；倒是由 於  Debug  的  Runtime  Library  加強了對錯誤的檢測，如堆記憶體分配，有時會出現  Debug  有錯 但  Release  正常的現象。應當指出的是，如果  Debug  有錯，即使  Release  正常，程式肯定是有  Bug  的，只不 過可能是  Release  版的某次執行沒有表現出來而已。 
  
2.  優化：這是造成錯誤的主要原因，因為關閉優化時源程式基本上是直接翻譯的，而開啟優化後編譯器會作出一系列假設。這類錯誤主要有以下幾種：  
(1)  幀指標 (Frame  Pointer)省略（簡稱  FPO  ）：在函式呼叫過程中，所有呼叫資訊（返回地址、引數）以及自動變數都是放在棧中的。若函式的宣告與實現不同（引數、返回值、呼叫方式），就會產生錯誤，但  Debug  方式下，棧的訪問通過  EBP  暫存器儲存的地址實現，如果沒 有發生陣列越界之類的錯誤（或是越界“不多”），函式通常能正常執行；Release  方式下，優化會省略  EBP  棧基址指標，這樣通過一個全域性 指標訪問棧就會造成返回地址錯誤是程式崩潰。C++  的強型別特效能檢查出大多數這樣的錯誤，但如果用了強制型別轉換，就不行了。你可以 在  Release  版本中強制加入  /Oy-  編譯選項來關掉幀指標省略，以確定是否此類錯誤。此類錯誤通常有：  

MFC訊息響應函式書寫錯誤。正確的應為  
afx_msg  LRESULT  OnMessageOwn(WPARAM  wparam,  LPARAM  lparam);  
ON_MESSAGE  巨集 包含強制型別轉換。防止這種錯誤的方法之一是重定義  ON_MESSAGE  巨集，把下列程式碼加到  stdafx.h  中 （在#include  "afxwin.h"之後）,函式原形錯誤時編譯會報錯  

(2)  volatile  型變數：volatile  告訴編譯器該變數可能被程式之外的未知方式修改（如系統、其他程式和執行緒）。優化程式為了使程式效能提高，常把一些變數放在暫存器中（類似於  register  關鍵字），而其他程式只能對該變數所在的記憶體進行修改，而暫存器中的 值沒變。如果你的程式是多執行緒的，或者你發現某個變數的值與預期的不符而你確信已正確的設定了，則很可能遇到這樣的問題。這種錯誤有時會表現為程式在最快 優化出錯而最小優化正常。把你認為可疑的變數加上  volatile  試試。  

(3)  變數優化：優化程式會根據變數的使用情況優化變數。例如，函式中有一個未被使用的變數，在  Debug  版中它有可能掩蓋一個陣列越界，而在  Release  版中，這個變數很可能被 優化調，此時陣列越界會破壞棧中有用的資料。當然，實際的情況會比這複雜得多。與此有關的錯誤有：  
    非法訪問，包括陣列越界、指標錯誤 等。例如  

j  雖然在陣列越界時已出了作用域，但其空間並未收回，因而  i  和  j  就會掩蓋越界。而  Release  版由於  i、j  並未其很大作用可能會被優化掉，從而使棧被破壞。  

3.  _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()  違反了斷言的思想，不能使程式程式碼和除錯程式碼完全分離， 最終可能會帶來很多麻煩。因此，專家們建議儘量少用這個巨集。  

一、"Debug是除錯版本，包括的程式資訊更多"  
補充：只有DEBUG版的程式才能設定斷點、單步執行、使用 TRACE/ASSERT等除錯輸出語句。REALEASE不包含任何除錯資訊，所以體積小、執行速度快。 

I.    記憶體分配問題   
   1.    變數未初始化。下面的程式在debug中執行的很好。   

   而在release中卻不行，因為debug中會自動給變數初始化found=FALSE,而在release版中則不會。所以儘可能的給變數、類或結構 初始化。   
    
   2.    資料溢位的問題   
   如： 

   在debug版中buffer的NULL覆蓋了counter的高位，但是除非counter>16M,什麼問題也 沒有。但是在release版 中，counter可能被放在暫存器中，這樣NULL就覆蓋了buffer下面的空間，可能就是函式的返回地址，這將導致 ACCESS    ERROR。   
    
   3.    DEBUG版和RELEASE版的記憶體分配方式是不同的    。如果你在DEBUG版中申請    ele    為    6*sizeof(DWORD)=24bytes,實際上分配給你的是32bytes（debug版以32bytes為單位分配），    而在release版，分配給你的就是24bytes（release版以8bytes為單位），所以在debug版中如果你寫ele[6],可能不會有 什麼問題，而在release版中，就有ACCESS    VIOLATE。   
    
   II.    ASSERT和VERIFY   
    
   1.    ASSERT在Release版本中是不會被編譯的。   
    
   ASSERT巨集是這樣定義的   

   實際上覆雜一些，但無關緊要。假如你在這些語句中加了程式中必須要有的程式碼   
   比如   

   
   這種時候Release版本中的pNewObj不會分配到空間   
    
   所以執行到下一個語句的時候程式會報該程式執行了非法操作的錯誤。這時可以用VERIFY    ：   

  
   這樣的話，程式碼在release版中就可以執行了。   
    
   III.    引數問題：   
    
   自定義訊息的處理函式，必須定義如下：   
   afx_msg    LRESULT    OnMyMessage(WPARAM,    LPARAM);   
   返回值必須是HRESULT型，否則Debug會過，而Release出錯   
    
   IV.    記憶體分配   
   保證資料建立和清除的統一性：如果一個DLL提供一個能夠建立資料的函式，那麼這個DLL同時應該提供一個函式銷燬這些資料。資料的建立和清除應該在同一 個層次上。   
    
   V.    DLL的災難   
   人們將不同版本DLL混合造成的不一致性形象的稱為    “動態連線庫的地獄“(DLL    Hell)    ，甚至微軟自己也這麼說 http://msdn.microsoft.com/library/techart/dlldanger1.htm)。   
    
   如果你的程式使用你自己的DLL時請注意：   
    
   1.    不能將debug和release版的DLL混合在一起使用。debug都是debug版，release版都是release版。   
   解決辦法是將debug和release的程式分別放在主程式的debug和release目錄下   
    
   2.    千萬不要以為靜態連線庫會解決問題，那隻會使情況更糟糕。   
    
   VI.    RELEASE版中的除錯    ：   
   1.    將ASSERT()    改為    VERIFY()    。找出定義在"#ifdef    _DEBUG"中的程式碼，如果在RELEASE版本中需要這些程式碼請將他們移到定義外。查詢TRACE(...)中程式碼，因為這些程式碼在RELEASE中 也不被編譯。    請認真檢查那些在RELEASE中需要的程式碼是否並沒有被便宜。   
   2.    變數的初始化所帶來的不同，在不同的系統，或是在DEBUG/RELEASE版本間都存在這樣的差異，所以請對變數進行初始化。   
   3.    是否在編譯時已經有了警告?請將警告級別設定為3或4,然後保證在編譯時沒有警告出現.   

   VII.    將Project    Settings"    中    "C++/C    "    專案下優化選項改為Disbale（Debug）。編譯器的優化可能導致許多意想不到的錯誤，請參http://www.pgh.net/~newcomer/debug_release.htm   
    
   1.    此外對RELEASE版本的軟體也可以進行除錯，請做如下改動：   
    
   在"Project Settings"中"C++/C"專案下設定"category"為"General"並且將"Debug    Info"設定為"Program Database"。   
    
   在"Link"專案下選中"Generate Debug Info"檢查框。   
    
   "Rebuild All"   
    
   如此做法會產生的一些限制：   
    
   無法獲得在MFC DLL中的變數的值。   
    
   必須對該軟體所使用的所有DLL工程都進行改動。   
    
   另：   
    
   1. MS BUG：MS的一份技術文件中表明，在VC5中對於DLL的"Maximize    Speed"優化選項 並未被完全支援，因此這將會引起記憶體錯誤並導致程式崩潰。   
    
   2. http://www.sysinternals.com/有 一個程式DebugView，用來捕捉OutputDebugString的輸出，執行起來後（估計是自設為system debugger）就可以觀看所有程式的OutputDebugString的輸出。此後，你可以脫離VC來執行你的程式並觀看除錯資訊。   
    
   3.    有一個叫Gimpel    Lint的靜態程式碼檢查工具，據說比較好用http://www.gimpel.com/    不過要化$的。 

Debug與Release不同的問題在剛開始編寫程式碼時會經常發生，99%是因為你的程式碼書寫錯誤而導致的，所以不要動不動就說系統問 題或編譯器問題，努力找找自己的原因才是根本。我從前就常常遇到這情況，經歷過一次次的教訓後我就開始注意了，現在我所寫過的程式碼我已經好久沒遇到這種問 題了。下面是幾個避免的方面，即使沒有這種問題也應注意一下： 
1. 注意變數的初始化，尤其是指標變數，陣列變數的初始化(很大的情況下另作考 慮了)。 
2. 自定義訊息及其他宣告的標準寫法 
3. 使用除錯巨集時使用後最好註釋掉 
4. 儘量使用 try - catch(...) 
5. 儘量使用模組，不但表達清楚而且方便除錯。