關於Debug Release

關於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. 盡量使用模組，不但表達清楚而且方便調試。

注1：

afc(afc) 網友提供：

 debug版初始化成0xcc是因為0xcc在x86下是一條int 3單步中斷指令，這樣程式如果跑飛了遇到0xcc就會停下來，這和單片機編程時一般將沒用的代碼空間填入jmp 0000語句是一樣地

注2：

 不知大家有沒有遇到過這種情況，具體原因我也不太清楚，是不是調用時按著預設的參數多分配了WPARAM+LPARAM的空間而破壞了應用程式的記憶體空間?還請高手來補充。

NightWolf 網友提供：我遇見過，好像是在函數調用的時候參數入棧的問題。因為MFC的訊息使用宏寫的，所以如果定義了OnMessage()的函數，編譯能夠通過，但是調用一次後，堆棧指標發生了位移。然後就。。。

Debug&Release 2

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    "_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：連結哪種運行時刻函數庫通常只對程式的效能產生影響。調試版本的    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    等選項造成錯誤的情況比較少，而且他們的效果顯而易見，比較容易發現。

Debug&Release 3

 Debug 通常稱為調試版本，它包含調試資訊，並且不作任何最佳化，便於程式員偵錯工具。Release 稱為發布版本，它往往是進行了各種最佳化，使得程式在代碼大小和運行速度上都是最優的，以便使用者很好地使用。

    Debug 和 Release 的真正秘密，在於一組編譯選項。下面列出了分別針對二者的選項（當然除此之外還有其他一些，如/Fd /Fo，但區別並不重要，通常他們也不會引起 Release 版錯誤，在此不討論）

 

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 版的程式

    遇到 Debug 成功但 Release 失敗，顯然是一件很沮喪的事，而且往往無從下手。如果你看了以上的分析，結合錯誤的具體表現，很快找出了錯誤，固然很好。但如果一時找不出，以下給出了一些在這種情況下的策略。

 

1.	前面已經提過，Debug 和 Release 只是一組編譯選項的差別，實際上並沒有什麼定義能區分二者。我們可以修改 Release 版的編譯選項來縮小錯誤範圍。如上所述，可以把 Release 的選項逐個改為與之相對的 Debug 選項，如 /MD 改為 /MDd、/O1 改為 /Od，或已耗用時間最佳化改為程式大小最佳化。注意，一次只改一個選項，看改哪個選項時錯誤消失，再對應該選項相關的錯誤，針對性地尋找。這些選項在 Project\Settings... 中都可以直接通過列表選取，通常不要手動修改。由於以上的分析已相當全面，這個方法是最有效。
2.	在編程過程中就要時常注意測試 Release 版本，以免最後代碼太多，時間又很緊。
3.	在 Debug 版中使用 /W4 警告層級，這樣可以從編譯器獲得最大限度的錯誤資訊，比如 if( i =0 )就會引起 /W4 警告。不要忽略這些警告，通常這是你程式中的 Bug 引起的。但有時 /W4 會帶來很多冗餘資訊，如 未使用的函數參數 警告，而很多訊息處理函數都會忽略某些參數。我們可以用: #progma warning(disable: 4702) //禁止//...#progma warning(default: 4702) //重新允許來暫時禁止某個警告，或使用#progma warning(push, 3) //設定警告層級為 /W3//...#progma warning(pop) //重設為 /W4來暫時改變警告層級，有時你可以只在認為可疑的那一部分代碼使用 /W4。
4.	你也可以像 Debug 一樣調試你的 Release 版，只要加入偵錯符號。在 Project/Settings... 中，選中 Settings for "Win32 Release"，選中 C/C++ 標籤，Category 選 General，Debug Info 選 Program Database。再在 Link 標籤 Project options 最後加上 "/OPT:REF" (引號不要輸)。這樣調試器就能使用 pdb 檔案中的偵錯符號。但調試時你會發現斷點很難設定，變數也很難找到——這些都被最佳化過了。不過令人慶幸的是，Call Stack 視窗仍然工作正常，即使幀指標被最佳化，棧資訊（特別是返回地址）仍然能找到。這對定位錯誤很有協助。

VC- Project Setting-Debug-Project Option文法解釋

　　-最佳化-

　　/O1 最小化空間 minimize space

　　/Op[-] 改善浮點數一致性 improve floating-pt consistency

　　/O2 最大化速度 maximize speed

　　/Os 優選代碼空間 favor code space

　　/Oa 假設沒有別名 assume no aliasing

　　/Ot 優選代碼速度 favor code speed

　　/Ob 內聯展開（預設 n=0） inline expansion (default n=0)

　　/Ow 假設交叉函數別名 assume cross-function aliasing

　　/Od 禁用最佳化（預設值） disable optimizations (default)

　　/Ox 最大化選項。(/Ogityb2 /Gs) maximum opts. (/Ogityb1 /Gs)

　　/Og 啟用全域最佳化 enable global optimization

　　/Oy[-] 啟用架構指標省略 enable frame pointer omission

　　/Oi 啟用內建函數 enable intrinsic functions

　　-代碼產生-

　　/G3 為 80386 進行最佳化 optimize for 80386

　　/G4 為 80486 進行最佳化 optimize for 80486

　　/GR[-] 啟用 C++ RTTI enable C++ RTTI

　　/G5 為 Pentium 進行最佳化 optimize for Pentium

　　/G6 為 Pentium Pro 進行最佳化 optimize for Pentium Pro

　　/GX[-] 啟用 C++ 異常處理（與 /EHsc 相同） enable C++ EH (same as /EHsc)

　　/EHs 啟用同步 C++ 異常處理 enable synchronous C++ EH

　　/GD 為 Windows DLL 進行最佳化 optimize for Windows DLL

　　/GB 為混合模型進行最佳化（預設） optimize for blended model (default)

　　/EHa 啟用非同步 C++ 異常處理 enable asynchronous C++ EH

　　/Gd __cdecl 呼叫慣例 __cdecl calling convention

　　/EHc extern“C”預設為 nothrow extern "C" defaults to nothrow

　　/Gr __fastcall 呼叫慣例 __fastcall calling convention

　　/Gi[-] 啟用增量編譯 enable incremental compilation

　　/Gz __stdcall 呼叫慣例 __stdcall calling convention

　　/Gm[-] 啟用最小重建 enable minimal rebuild

　　/GA 為 Windows 應用程式進行最佳化 optimize for Windows Application

　　/Gf 啟用字串池 enable string pooling

　　/QIfdiv[-] 啟用 Pentium FDIV 修複 enable Pentium FDIV fix

　　/GF 啟用唯讀字串池 enable read-only string pooling

　　/QI0f[-] 啟用 Pentium 0x0f 修複 enable Pentium 0x0f fix

　　/Gy 分隔連結器函數 separate functions for linker

　　/GZ 啟用運行時調試檢查 enable runtime debug checks

　　/Gh 啟用鉤子函數調用 enable hook function call

　　/Ge 對所有函數強制堆棧檢查 force stack checking for all funcs

　　/Gs[num] 禁用堆棧檢查調用 disable stack checking calls

　　-輸出檔案-

　　/Fa 命名程式集列表檔案 name assembly listing file

　　/Fo 命名物件檔案 name object file

　　/FA[sc] 配置程式集列表 configure assembly listing

　　/Fp 命名先行編譯標頭檔 name precompiled header file

　　/Fd 命名 .PDB 檔案 name .PDB file

　　/Fr 命名源瀏覽器檔案 name source browser file

　　/Fe 命名可執行檔 name executable file

　　/FR 命名擴充 .SBR 檔案 name extended .SBR file

　　/Fm 命名對應檔 name map file

　　-前置處理器-

　　/FI 命名強制包含檔案 name forced include file

　　/C 不吸取注釋 don't strip comments

　　/U 移除預定義宏 remove predefined macro

　　/D{=|#} 定義宏 define macro

　　/u 移除所有預定義宏 remove all predefined macros

　　/E 將預先處理定向到標準輸出 preprocess to stdout

　　/I 添加到包含檔案的搜尋路徑 add to include search path

　　/EP 將預先處理定向到標準輸出，不要帶行號 preprocess to stdout, no #line

　　/X 忽略“標準位置” ignore "standard places"

　　/P 預先處理到檔案 preprocess to file

　　-語言-

　　/Zi 啟用調試資訊 enable debugging information

　　/Zl 忽略 .OBJ 中的預設庫名 omit default library name in .OBJ

　　/ZI 啟用調試資訊的“編輯並繼續”功能 enable Edit and Continue debug info

　　/Zg 產生函數原型 generate function prototypes

　　/Z7 啟用舊式調試資訊 enable old-style debug info

　　/Zs 只進行語法檢查 syntax check only

　　/Zd 僅要行號調試資訊 line number debugging info only

　　/vd{0|1} 禁用/啟用 vtordisp disable/enable vtordisp

　　/Zp[n] 在 n 位元組邊界上封裝結構 pack structs on n-byte boundary

　　/vm 指向成員的指標類型 type of pointers to members

　　/Za 禁用擴充（暗指 /Op） disable extensions (implies /Op)

　　/noBool 禁用“bool”關鍵字 disable "bool" keyword

　　/Ze 啟用擴充（預設） enable extensions (default)

　　- 雜項 -

　　/?, /help 列印此協助訊息 print this help message

　　/c 只編譯，不連結 compile only, no link

　　/W 設定警告層級（預設 n=1） set warning level (default n=1)

　　/H 最大化外部名稱長度 max external name length

　　/J 預設 char 類型是 unsigned default char type is unsigned

　　/nologo 取消顯示著作權訊息 suppress copyright message

　　/WX 將警告視為錯誤 treat warnings as errors

　　/Tc 將檔案編譯為 .c compile file as .c

　　/Yc 建立 .PCH 檔案 create .PCH file

　　/Tp 將檔案編譯為 .cpp compile file as .cpp

　　/Yd 將調試資訊放在每個 .OBJ 中 put debug info in every .OBJ

　　/TC 將所有檔案編譯為 .c compile all files as .c

　　/TP 將所有檔案編譯為 .cpp compile all files as .cpp

　　/Yu 使用 .PCH 檔案 use .PCH file

　　/V 設定版本字串 set version string

　　/YX 自動的 .PCH 檔案 automatic .PCH

　　/w 禁用所有警告 disable all warnings

　　/Zm 最大記憶體配置（預設為 %） max memory alloc (% of default)

　　-連結-

　　/MD 與 MSVCRT.LIB 連結 link with MSVCRT.LIB

　　/MDd 與 MSVCRTD.LIB 調試庫連結 link with MSVCRTD.LIB debug lib

　　/ML 與 LIBC.LIB 連結 link with LIBC.LIB

　　/MLd 與 LIBCD.LIB 調試庫連結 link with LIBCD.LIB debug lib

　　/MT 與 LIBCMT.LIB 連結 link with LIBCMT.LIB

　　/MTd 與 LIBCMTD.LIB 調試庫連結 link with LIBCMTD.LIB debug lib

　　/LD 建立 .DLL Create .DLL

　　/F 設定堆棧大小 set stack size

　　/LDd 建立 .DLL 調試庫 Create .DLL debug libary

　　/link [連結器選項和庫] [linker options and libraries]