青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

road420

導航

<2009年11月>
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345

統計

常用鏈接

留言簿(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 深邃者 閱讀(315) 評論(0)  編輯 收藏 引用


只有注冊用戶登錄后才能發表評論。
網站導航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            欧美成人激情视频免费观看| 欧美国产日韩精品| 亚洲一区在线看| 欧美日韩国产一区二区三区地区| 亚洲激情视频在线观看| 亚洲国产天堂久久综合| 欧美精品乱人伦久久久久久 | 免费一级欧美片在线播放| 在线观看欧美| 欧美激情一区二区三区在线| 欧美大片国产精品| 亚洲午夜精品久久| 欧美一区二区三区在线观看视频 | 国产精品一区二区久久| 久久精品天堂| 老色鬼精品视频在线观看播放| 亚洲三级视频在线观看| 亚洲卡通欧美制服中文| 国产精品盗摄久久久| 久久久久久国产精品一区| 久久精品中文字幕免费mv| 亚洲国产三级在线| 一区二区三区日韩欧美精品| 国产亚洲欧洲997久久综合| 免费一级欧美片在线播放| 欧美精品一线| 久久aⅴ国产欧美74aaa| 欧美二区在线观看| 欧美专区日韩视频| 欧美高清视频免费观看| 欧美一区二区三区男人的天堂| 久久精品夜夜夜夜久久| 亚洲一区二区日本| 久久只精品国产| 亚洲欧美国产不卡| 久久人人超碰| 亚洲一区二区三区在线看| 久久精品国产一区二区三区免费看 | 午夜精品一区二区三区在线视| 亚洲国产精品99久久久久久久久| 日韩午夜剧场| 在线欧美亚洲| 午夜精品久久久久久久久久久久 | 99国产欧美久久久精品| 亚洲欧美日韩综合| 夜夜爽av福利精品导航| 久久久久久亚洲精品杨幂换脸| 亚洲免费在线视频| 欧美日本一道本在线视频| 免费在线成人av| 国产欧美一区二区精品秋霞影院 | 久久米奇亚洲| 国产精品久久一卡二卡| 亚洲日本欧美日韩高观看| 一区二区在线不卡| 久久精品国产一区二区三区| 欧美亚洲日本国产| 国产精品久久久久久av福利软件 | 久久久欧美一区二区| 久久精品二区三区| 国产精品亚洲精品| 亚洲一区三区视频在线观看| 一本色道久久99精品综合| 欧美刺激性大交免费视频| 毛片一区二区| 在线国产日韩| 久久久噜噜噜久久久| 久久成人综合网| 国产亚洲欧美日韩日本| 欧美一区国产一区| 久久久久网站| 精东粉嫩av免费一区二区三区| 欧美在线视频免费观看| 狼狼综合久久久久综合网| 激情久久久久| 欧美99在线视频观看| 亚洲国产精品视频| 一区二区三区蜜桃网| 欧美日韩国产首页| 一本久久综合亚洲鲁鲁| 午夜久久久久| 黑人极品videos精品欧美裸| 欧美专区在线播放| 男同欧美伦乱| 日韩午夜电影av| 欧美日韩伦理在线| 午夜精品美女久久久久av福利| 久久精品在线播放| 1204国产成人精品视频| 欧美成人中文| 一区二区日韩精品| 久久噜噜噜精品国产亚洲综合| 亚洲春色另类小说| 欧美日韩亚洲不卡| 午夜精品久久久久| 欧美高清视频免费观看| 在线视频亚洲| 国产一区二区三区在线观看视频 | 亚洲国产综合在线| 亚洲免费观看在线观看| 国产精品久久网站| 美女免费视频一区| 亚洲另类春色国产| 久久手机精品视频| 99精品欧美一区二区三区| 国产精品一区一区三区| 另类图片综合电影| 亚洲一区中文| 亚洲第一中文字幕在线观看| 亚洲欧美视频| 亚洲国产日韩欧美| 国产精品一区二区在线观看不卡| 久久一区中文字幕| 亚洲一区二区在线看| 亚洲黄色视屏| 久久久久久一区二区三区| 亚洲美女网站| 黄色亚洲精品| 国产精品美女xx| 欧美精品一区三区| 久久久亚洲人| 午夜精品视频在线观看| 日韩视频在线观看国产| 免费在线播放第一区高清av| 性色av一区二区三区红粉影视| 日韩视频在线一区二区| 影音先锋成人资源站| 国产精品综合网站| 欧美视频网站| 欧美精品二区| 欧美va天堂在线| 久久国产精品第一页| 亚洲一区激情| 亚洲一区二区精品在线观看| 亚洲激情在线播放| 亚洲成色精品| 久久国产精品99久久久久久老狼| 日韩视频免费观看高清在线视频 | 亚洲欧洲综合| 国内揄拍国内精品少妇国语| 欧美日韩中文字幕在线视频| 欧美成在线观看| 久久一区二区三区四区| 久久美女艺术照精彩视频福利播放| 午夜精品影院| 欧美一区二区三区久久精品茉莉花| 亚洲在线观看视频网站| 中日韩男男gay无套| 国产精品99久久久久久有的能看 | 欧美一区二区三区免费看| 亚洲欧美日韩国产一区二区三区 | 一区二区三欧美| 日韩小视频在线观看| 亚洲精品日本| 日韩视频亚洲视频| 一区二区精品在线观看| 亚洲天堂男人| 欧美亚洲综合另类| 久久精视频免费在线久久完整在线看| 欧美一级淫片aaaaaaa视频| 欧美一区二区三区视频在线| 久久精品30| 欧美va亚洲va国产综合| 亚洲国产成人久久| 日韩视频免费观看高清完整版| 中文精品在线| 性欧美18~19sex高清播放| 欧美在线视频二区| 欧美va日韩va| 国产精品久久久久久久久搜平片| 国产精品亚洲综合色区韩国| 在线播放视频一区| 亚洲精品中文字| 亚洲欧美日韩一区二区| 久久久国产午夜精品| 欧美激情无毛| 亚洲伊人网站| 久久亚洲综合| 欧美午夜宅男影院| 韩日精品在线| 亚洲性感美女99在线| 久久九九国产| 亚洲美女视频网| 久久精品国产69国产精品亚洲| 免费看的黄色欧美网站| 国产精品久久久亚洲一区 | 国产精品色网| 激情综合视频| 亚洲一区二区黄| 欧美不卡视频一区| 在线一区二区视频| 快she精品国产999| 国产精品视频一二| 亚洲国产日韩欧美综合久久| 先锋资源久久| 夜夜嗨av色综合久久久综合网| 久久国产主播精品| 国产精品裸体一区二区三区| 亚洲人成在线播放| 免费不卡视频|