Debug版本包括調試信息,所以要比Release版本大很多(可能大數百K至數M)。

    至于是否需要DLL支持,主要看你采用的編譯選項。如果是基于 ATL的,則Debug和Release版本對DLL的要求差不多。如果采用的編譯選項為使用MFC動態庫,則需要MFC42D.DLL等庫支持,而Release版本需要MFC42.DLL支持。

    Release Build不對源代碼進行調試,不考慮MFC的診斷宏,使用的是MFC Release庫,編譯時對應用程序的速度進行優化,而Debug Build則正好相反,它允許對源代碼進行調試,可以定義和使用MFC的診斷宏,采用MFC Debug庫,對速度沒有優化。    

一、Debug 和 Release 編譯方式的本質區別  
 
    Debug通常稱為調試版本,它包含調試信息,并且不作任何優化,便于程序員調試程序。Release 稱為發布版本,它往往是進行了各種優化,使得程序在代碼大小和運行速度上都是最優的,以便用戶很好地使用。  
    Debug 和 Release 的真正秘密,在于一組編譯選項。下面列出了分別針對二者的選項(當然除此之外還有其他一些,如/Fd、/Fo,但區別并不重要,通常他們也不會引起  Release  版錯誤,在此不討論)  
    1、Debug  版本:  
/MDd /MLd 或 /MTd:使用 Debug runtime library(調試版本的運行時刻函數庫)  
/Od:關閉優化開關  
/D "_DEBUG":相當于 #define _DEBUG,打開編譯調試代碼開關(主要針對assert函數)  
/ZI:創建  Edit  and  continue(編輯繼續)數據庫,這樣在調試過程中如果修改了源代碼不需重新編譯  
/GZ:可以幫助捕獲內存錯誤  
/Gm:打開最小化重鏈接開關,減少鏈接時間  
    2、Release  版本:    
/MD /ML 或 /MT  使用發布版本的運行時刻函數庫  
/O1 或 /O2:優化開關,使程序最小或最快  
/D "NDEBUG":關閉條件編譯調試代碼開關(即不編譯assert函數)  
/GF:合并重復的字符串,并將字符串常量放到只讀內存,防止被修改  
    實際上,Debug  和  Release  并沒有本質的界限,他們只是一組編譯選項的集合,編譯器只是按照預定的選項行動。事實上,我們甚至可以修改這些選項,從而得到優化過的調試版本或是帶跟蹤語句的發布版本。  
 
二、哪些情況下  Release  版會出錯  
 
    有了上面的介紹,我們再來逐個對照這些選項看看  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"之后),函數原形錯誤時編譯會報錯  
#undef ON_MESSAGE  
#define ON_MESSAGE(message, memberFxn) \  
message, 0, 0, 0, AfxSig_lwl, \  
(AFX_PMSG)(AFX_PMSGW)(static_cast< LRESULT (AFX_MSG_CALL \  
CWnd::*)(WPARAM, LPARAM) > (&memberFxn) },  
(2)  volatile  型變量:

volatile 告訴編譯器該變量可能被程序之外的未知方式修改(如系統、其他進程和線程)。優化程序為了使程序性能提高,常把一些變量放在寄存器中(類似于 register 關鍵字),而其他進程只能對該變量所在的內存進行修改,而寄存器中的值沒變。如果你的程序是多線程的,或者你發現某個變量的值與預期的不符而你確信已正確的設置了,則很可能遇到這樣的問題。這種錯誤有時會表現為程序在最快優化出錯而最小優化正常。把你認為可疑的變量加上 volatile 試試。  
(3)  變量優化:

優化程序會根據變量的使用情況優化變量。例如,函數中有一個未被使用的變量,在 Debug 版中它有可能掩蓋一個數組越界,而在 Release 版中,這個變量很可能被優化,此時數組越界會破壞棧中有用的數據。當然,實際的情況會比這復雜得多。與此有關的錯誤有:  
非法訪問,包括數組越界、指針錯誤等。例如  
void  fn(void)  
{  
    int  i;  
    i  =  1;  
    int  a[4];  
    {  
        int  j;  
        j  =  1;  
    }  
    a[-1]  =  1;//當然錯誤不會這么明顯,例如下標是變量  
    a[4]  =  1;  
}  
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() 違反了斷言的思想,不能使程序代碼和調試代碼完全分離,最終可能會帶來很多麻煩。因此,專家們建議盡量少用這個宏。  


4.  /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  版中未初始化的變量是隨機的,這有可能使指針指向一個有效地址而掩蓋了非法訪問。  

    除此之外,/Gm  /GF  等選項造成錯誤的情況比較少,而且他們的效果顯而易見,比較容易發現。  

簡短地說:
    Release是發行版本,比Debug版本有一些優化,文件比Debug文件小。Debug是調試版本,包括的程序信息更多。Release方法: build->batch,build->build就OK. 只有DEBUG版的程序才能設置斷點、單步執行、使用TRACE/ASSERT等調試輸出語句。REALEASE不包含任何調試信息,所以體積小、運行速度快。