2. 程式人生 > >VC中debug和release版本的區別

VC中debug和release版本的區別

阿新 • • 發佈：2019-01-21

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之本質區別的討論本文主要包含如下內容：
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"優化選項並未被完全支援，因此這將會引起記憶體錯誤並導致程式崩潰。

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

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檔案中摘出來的： 

  1. #ifdef NDEBUG  
  2. #define assert(_Expression)     ((void)0)  
  3. #else  /* NDEBUG */  
  4. #ifdef __cplusplus  
  5. extern "C" {  
  6. #endif  /* __cplusplus */  
  7. _CRTIMP void __cdecl _wassert(__in_z const wchar_t * _Message, __in_z 

    相關推薦

    VC中debug和release版本的區別

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

    debug和release版本的區別

    模式 exe 信息 容量 都是 release 中斷 編譯 一個 Debug：調試版本，包含調試信息，所以容量比Release大很多，並且不進行任何優化（優化會使調試復雜化，因為源代碼和生成的指令間關系會更復雜），便於程序員調試。 Debug模式下生成兩個文件，除了.e

    C++ 程式DEBUG和RELEASE版本的區別

    Relase版本對程式作了各種優化的，使得程式在大小和速度上達到最優。Debug版本，包含程式的除錯資訊，方便程式設計師做除錯。Relase版本是不利於程式的除錯。 Debug和Relase版本編譯選項 Debug 和 Release 的真正區別，在於一組編

    C++ debug和release版本的區別及除錯技巧

    一、Debug 和 Release 編譯方式的本質區別    Debug 通常稱為除錯版本，它包含除錯資訊，並且不作任何優化，便於程式設計師除錯程式。Release 稱為釋出版本，它往往是進行了各種優化，使得程式在程式碼大小和執行速度上都是最優的，以便使用者很好地使用。  

    cordova環境搭建以及將vue的webapp打包成ios和安卓的debug和release版本app

    簡介 cordova可以幫我們將一個webApp打包成安卓apk和ios的App，本文詳細描述了cordova的環境搭建以及打包vue專案的webapp成手機端的App的詳細過程，打包的app分為debug版本的除錯版以及能上線的release版本，其中都會做詳細介紹，文章中會也會描述整個環節遇

    VC++中 PostMessage和SendMessage的區別

    　　函式功能：該函式為一個訊息檢查執行緒訊息佇列，並將該訊息（如果存在）放於指定的結構。　　函式原型：BOOL PeekMessage（LPMSG IpMsg，HWND hWnd，UINT wMSGfilterMin，UINT wMsgFilterMax，UINT wRemoveMsg）；　　引數：　　lpM

    解決VS中Debug與Release版本切換的問題

    最近在使用PCL以及VTK等開發庫，但是使用過程中總會出現Debug與Release版本之間切換的問題，完全按照網上各種大牛的教程來配置的開發環境，為啥會爆出各種錯誤呢，一開始我也是一頭霧水，明明在Debug或者Release模式下執行的好好地，可是切換模式後奇怪的錯誤

    Visual Studio中Debug和Release

    概念 Debug通常稱為除錯版本，它包含除錯資訊，並且不作任何優化，便於程式設計師除錯程式。 Release稱為釋出版本，它往往是進行了各種優化，使得程式在程式碼大小和執行速度上都是最優的，以便使用者很好地使用。 Debug模式下的命令列 其各個命令

    VS2015編譯GEOS的debug和release版本

    image 雙擊 cmake efi 找到 makefile 嘗試 man 命令 目前GEOS最新的3.7.1版本支持camke進行編譯。經過嘗試發現通過cmake生成的工程在vs2015下面編譯的時候還是存在問題，而且在中文網上也沒找到解決方案。 所以還是采用了nmak

    ios 學習之 debug和release版本的執行

    不管在什麼平臺上軟體都有debug和release版本的差別，雖然本質上都是-O -g這些選項的差別，對應與開發著debug和release更多的概念上的差別，debug是面向自己的release是面向客戶的。 我們說一下在xcode上怎麼配置debug和release。

    cmake編譯Debug和Release版本的注意點

    在CMakeLists.txt中首先可以定義編譯的模式到底是Debug版本還是Release版本，在Terminal中直接編譯，也可以進行引數定義，不進行特殊定義應該都是Release版本。 但是LZ剛開始使用的是Kdevelop這個IDE，然後就刷刷刷nex

    DEBUG和RELEASE的區別

    在網上看到的一篇轉載過來 經常在 CSDN 上看見有人問 Debug 執行正常但 Release 失敗的問題。以往的討論往往是 經驗性的，並沒有指出會這樣的真正原因是什麼，要想找出真正的原因通常要憑運氣。最 近我看了一些這方面的書，又參考了 CSDN 上的一些帖子，然後深入研究了一下關於二者 的不同。以

    VC++中Debug除錯版本和Release發行版本的區別

    在寫程式碼過程中，發現 Debug 下執行正常，Release 下就會出現問題，百思不得其解，而Release 下又無法進行除錯，於是只能採用printf方式逐步定位到問題所在處，才發現原來是給定的一個數組未初始化，導致後面處理異常。網上查找了些資料，在這 羅列彙總下，做為備忘～  一

    vs中的程序有debug和release兩個版本的區別

    不同的 上進 BE 使用 的區別 debug 存在 通過 最優 vs中的程序有debug和release兩個版本，Debug通常稱為調試版本，通過一系列編譯選項的配合，編譯的結果通常包含調試信息，而且不做任何優化，以為開發 人員提供強大的應用程序調試能力。而Release通

    cmakelist中區分debug和release下對應的庫版本

    add_library(${LIBRARY_NAME} ${SOURCES} ${HEADERS})//生成一個對應的Debug庫，用來與Release版本的庫區分set_target_properties(${LIBRARY_NAME} PROPERTIES OUTPUT_NAME "${LIBR

    Android debug和release的版本區別, 涉及到的混淆

    1.背景 有關debug,release版本的問題,還有混淆 ,今天查到了一篇csdn的部落格,為了讓自己記憶更深刻,自己再敲一遍加深印象!本文只記錄一些簡單的概念,沒有深刻研究! 2.參考 因為是借用的嘛!標註一下,我現在判別不出他們寫的好不

    Debug和Release區別

    包含 自己 cat 發布 問題 一次 版本 catch 聲明 Debug 和 Release 的區別 Debug 通常稱為調試版本，它包含調試信息，並且不作任何優化，便於程序員調試程序。Release 稱為發布版本，它往往是進行了各種優化，使得程序在代碼大小

    maven snapshot和release版本的區別（轉）

    依賴 註意 發行版 str 設置 方便 版本更新 版本庫 編譯打包 在使用maven過程中，我們在開發階段經常性的會有很多公共庫處於不穩定狀態，隨時需要修改並發布，可能一天就要發布一次，遇到bug時，甚至一天要發布N次。我們知道，maven的依賴管理是基於版本管理的，對於發

    項目發布Debug和Release版的區別

    pdb 斷點 關閉 ont and echart TE har 討論 https://www.cnblogs.com/taiyonghai/p/6126074.html 一、Debug和Release的區別 　　Debug：調試版本，包含調試信息，所以容量比Releas

    VS中生成、清理專案、除錯、開始執行（不除錯）、Debug 和 Release等之間的差別

    一、生成和又一次生成 “生成”的時候僅僅對你修改過的檔案又一次生成沒有修改過的檔案不會又一次生成。 “又一次生成”是對全部的檔案都又一次生成。 以cpp為例當你僅僅修改某些.cpp之類的檔案的時候能夠用生成省了編譯沒有修改的那些些檔案的時間；可是修改了某些.h之類的檔案最好用又