• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            road420

            導航

            <2009年10月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            統計

            常用鏈接

            留言簿(2)

            隨筆檔案

            文章檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            Debug 和 Release

            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  版錯誤,在此不討論)  

            Debug  版本:  
            /MDd  /MLd  或  /MTd  使用  Debug  runtime  library(調試版本的運行時刻函數庫)  
            /Od  關閉優化開關  
            /D  &quot;_DEBUG&quot;  相當于  #define  _DEBUG,打開編譯調試代碼開關(主要針對  
            assert函數)  
            /ZI  創建  Edit  and  continue(編輯繼續)數據庫,這樣在調試過  
            程中如果修改了源代碼不需重新編譯  
            /GZ  可以幫助捕獲內存錯誤  
            /Gm  打開最小化重鏈接開關,減少鏈接時間  

            Release  版本:    
            /MD  /ML  或  /MT  使用發布版本的運行時刻函數庫  
            /O1  或  /O2  優化開關,使程序最小或最快  
            /D  &quot;NDEBUG&quot;  關閉條件編譯調試代碼開關(即不編譯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  &quot;afxwin.h&quot;之后),函數原形錯誤時編譯會報錯  
            #undef  ON_MESSAGE  
            #define  ON_MESSAGE(message,  memberFxn)  \  
            {  message,  0,  0,  0,  AfxSig_lwl,  \  
            (AFX_PMSG)(AFX_PMSGW)(static_cast&lt;  LRESULT  (AFX_MSG_CALL  \  
            CWnd::*)(WPARAM,  LPARAM)  &gt;  (&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-&gt;batch  build-&gt;build就OK.  

            -----------------------------------------------------  

            一、&quot;Debug是調試版本,包括的程序信息更多&quot;  

            補充:只有DEBUG版的程序才能設置斷點、單步執行、使用TRACE/ASSERT等調試輸出語句。REALEASE不包含任何調試信息,所以體積小、運行速度快。  

            二、一般發布release的方法除了hzh_shat(水)  所說的之外,還可以project-&gt;Set  Active  Config,選中release版本。此后,按F5或F7編譯所得的結果就是release版本

            posted on 2009-11-21 22:39 深邃者 閱讀(286) 評論(0)  編輯 收藏 引用

            亚洲日韩欧美一区久久久久我| 精品无码久久久久久国产| 久久久精品人妻一区二区三区蜜桃| 久久中文字幕人妻丝袜| 久久国产亚洲精品无码| 久久精品成人欧美大片| 久久99国产综合精品免费| 久久综合成人网| 久久777国产线看观看精品| 欧美久久天天综合香蕉伊| 丰满少妇人妻久久久久久| 超级碰碰碰碰97久久久久| 久久er热视频在这里精品| 国内精品人妻无码久久久影院导航 | 亚洲а∨天堂久久精品| 色诱久久久久综合网ywww | 无码人妻久久一区二区三区免费丨| 中文字幕久久欲求不满| 日日躁夜夜躁狠狠久久AV| 亚洲婷婷国产精品电影人久久| 99久久婷婷国产综合亚洲| 无码人妻久久久一区二区三区| 久久中文字幕视频、最近更新| 伊人久久综在合线亚洲2019 | 中文字幕久久精品| 久久最新免费视频| 国产精品青草久久久久福利99 | 久久亚洲AV无码精品色午夜| 久久久久久久亚洲精品| 久久线看观看精品香蕉国产| 丰满少妇人妻久久久久久| 精品国产一区二区三区久久久狼| 伊人久久大香线蕉av一区| 久久亚洲sm情趣捆绑调教| 久久99这里只有精品国产| 国产精品久久新婚兰兰| 伊人精品久久久久7777| 欧美黑人激情性久久| 久久精品国产久精国产果冻传媒 | 无码伊人66久久大杳蕉网站谷歌 | 色综合久久中文色婷婷|