剛接觸到MFC編程的人往往會被MFC?向?qū)傻母鞣N宏定義和預(yù)處理指令所嚇倒，但是預(yù)處理和宏定義又是C語言的一個強(qiáng)大工具。使用它們可以進(jìn)行簡單的源代碼控制，版本控制，預(yù)警或者完成一些特殊的功能。
一個經(jīng)典的例子
使用預(yù)處理與宏定義最經(jīng)典的例子莫過于加在一個頭文件中以避免頭文件被兩次編譯。試想這種的情況，有一個文件headerfile.h?它被包含在headerfile1.h中，同時在headerfile2.h?中也被包含了，現(xiàn)在有一個CPP文件，implement.cpp?包含了headerfile1.h?和headerfile2.h：
#include?“headerfile1.h”
#include?“headerfile2.h”?
假設(shè)headerfile.h?中定義了一個全局變量?iglobal?。
int?iglobal;??
在編譯的時候編譯器兩次編譯headerfile，也就會發(fā)現(xiàn)iglobal被定義了兩次，這時就會發(fā)生變量重定義的編譯錯誤。
傳統(tǒng)的解決辦法是使用#ifdef?以及#endif?來避免頭文件的重復(fù)編譯，在上面的例子中，只需要加上這么幾行：
#ifndef?smartnose_2002_6_21_headerfile_h
#define?smartnose_2002_6_21_headerfile_h
int?iglobal;
#endif?
仔細(xì)的考慮上面的宏定義，會發(fā)現(xiàn)當(dāng)編譯器編譯過一次headerfile.h以后，smartnose_2002_6_21_headerfile_h?這個宏就被定義了，以后對headerfile.h的編譯都會跳過int?iglobal?這一行。當(dāng)然smartnose_2002_6_21_headerfile_h?這個宏是可以任意定義的，但是這個宏本身不能和其它文件中定義的宏重復(fù)，所以MFC在自動生成的文件中總是使用一個隨機(jī)產(chǎn)生的長度非常長的宏，但我覺得這沒有必要，我建議在這個宏中加入一些有意義的信息，比方作者，文件名，文件創(chuàng)建時間等等，因為我們有時候會忘記在注釋中加入這些信息。
在VC.Net?中我們不會再看見這些宏定義了，因為在這里會普遍使用一個預(yù)處理指令：
#pragma?once?
只要在頭文件的最開始加入這條指令就能夠保證頭文件被編譯一次，這條指令實際上在VC6中就已經(jīng)有了，但是考慮到兼容性并沒有太多的使用它。
源代碼版本控制
當(dāng)我們?yōu)樵S多平臺開發(fā)多個版本的時候預(yù)編譯指令和宏定義也能夠幫我們的忙。假設(shè)我們現(xiàn)在為WINDOWS?和LINUX開發(fā)了一套軟件，由于這兩種系統(tǒng)的不同，我們不得不在程序控制源代碼的版本。比方內(nèi)存的分配，我們可以在LINUX上使用標(biāo)準(zhǔn)C的malloc?函數(shù)，但是我們希望在?WINDOWS上使用HeapAlloc?API。下面的代碼演示了這種情況：
main()
{
………………..
#ifdef?_WINDOWS_PLATFORM
HeapAlloc(5);
#else
malloc(5);
#endif
………………..
}?
當(dāng)我們在WINDOWS?平臺上編譯此程序的時候，只需要定義_WINDOWS_PLATFORM這個宏，那么HeapAlloc這條語句就能夠起作用了。這樣就能夠讓我們在同一個文件中為不同的平臺實現(xiàn)不同版本的代碼，同時保持程序的良好結(jié)構(gòu)。在許多情況下，我們還可以為一個方法使用不同的算法，然后用宏定義來針對不同的情況選擇其中的一個進(jìn)行編譯。這在MFC應(yīng)用程序中是使用得最多的。最明顯的就是文件中經(jīng)常存在的
#ifdef?_DEBUG
…………………….some?code………..
#endif?
這樣的代碼，這些代碼在應(yīng)用程序的調(diào)試版（DEBUG）中會發(fā)揮其作用。
#Pragma?指令
在所有的預(yù)處理指令中，#Pragma?指令可能是最復(fù)雜的了，它的作用是設(shè)定編譯器的狀態(tài)或者是指示編譯器完成一些特定的動作。其格式一般為
#Pragma?Para
其中Para?為參數(shù)，下面來看一些常用的參數(shù)。
message?參數(shù)。?Message?參數(shù)是我最喜歡的一個參數(shù)，它能夠在編譯信息輸出窗口中輸出相應(yīng)的信息，這對于源代碼信息的控制是非常重要的。其使用方法為：
#Pragma?message(“消息文本”)
當(dāng)編譯器遇到這條指令時就在編譯輸出窗口中將消息文本打印出來。
當(dāng)我們在程序中定義了許多宏來控制源代碼版本的時候，我們自己有可能都會忘記有沒有正確的設(shè)置這些宏，此時我們可以用這條指令在編譯的時候就進(jìn)行檢查。假設(shè)我們希望判斷自己有沒有在源代碼的什么地方定義了_X86這個宏可以用下面的方法
#ifdef?_X86
#Pragma?message(“_X86?macro?activated!”)
#endif?
當(dāng)我們定義了_X86這個宏以后，應(yīng)用程序在編譯時就會在編譯輸出窗口里顯示“_X86?macro?activated!”。我們就不會因為不記得自己定義的一些特定的宏而抓耳撓腮了。
另一個使用得比較多的pragma參數(shù)是code_seg。格式如：
#pragma?code_seg(?["section-name"[,"section-class"]?]?)?
它能夠設(shè)置程序中函數(shù)代碼存放的代碼段，當(dāng)我們開發(fā)驅(qū)動程序的時候就會使用到它。
最后一個比較常用的就是上面所說的#pragma?once?指令了。
VC預(yù)定義的宏
在VC中有一類宏并不是由用戶用#define語句定義的，而是編譯器本身就能夠識別它們。這些宏的作用也是相當(dāng)大的。讓我們來看第一個，也是MFC中使用得最頻繁的一個:__FILE__?。
當(dāng)編譯器遇到這個宏時就把它展開成當(dāng)前被編譯文件的文件名。好了，我們馬上就可以想到可以用它來做什么，當(dāng)應(yīng)用程序發(fā)生錯誤時，我們可以報告這個錯誤發(fā)生的程序代碼在哪個文件里，比方在文件test.cpp中有這樣的代碼：
try
{
char?*?p=new(char[10]);
}
catch(CException?*e?)
{
TRACE(“?there?is?an?error?in?file:?%s\n”,__FILE__);
}?
在程序運行的時候，如果內(nèi)存分配出現(xiàn)了錯誤，那么在調(diào)試窗口中會出現(xiàn)there?is?an?error?in?file:?test.cpp?這句話，當(dāng)然，我們還可以把這個錯誤信息顯示在別的地方。
如果我們還能夠記錄錯誤發(fā)生在哪一行就好了，幸運的是，與__FILE__宏定義一樣，還有一個宏記錄了當(dāng)前代碼所在的行數(shù)，這個宏是__LINE__。使用上面的兩個宏，我們可以寫出一個類似于VC提供的ASSERT語句。下面是方法
#define?MyAssert(x)?if(!(x))?MessageBox(__FILE__,__LINE__,NULL,MB_OK);?
我們在應(yīng)用程序中可以象使用ASSERT語句一樣使用它，在錯誤發(fā)生時，它會彈出一個對話框，其標(biāo)題和內(nèi)容告訴了我們錯誤發(fā)生的文件和代碼行號，方便我們的調(diào)試，這對于不能使用ASSERT語句的項目來說是非常有用的。
除了這兩個宏以外，還有記錄編譯時間的__TIME__，記錄日期的__DATE__，以及記錄文件修改時間的__TIMESTAMP__宏。
使用這些預(yù)定義的宏，我們幾乎可以生成和VC能夠生成的一樣完整的源代碼信息報表。
結(jié)論
翻開MFC和Linux的源代碼，宏定義幾乎占據(jù)了半邊天，消息映射，隊列操作，平臺移植，版本管理，甚至內(nèi)核模塊的拆卸安裝都用宏定義完成。毫不夸張的說，有些文件甚至就只能看見宏定義。所以學(xué)習(xí)宏定義，熟練的使用宏定義對于學(xué)習(xí)C語言乃至VC都是非常關(guān)鍵的。
在上一篇文章中，我演示了幾個常用的宏定義和預(yù)處理指令，但可以說這些都是相當(dāng)常規(guī)的技巧。下面要介紹的宏定義與預(yù)處理指令的用法也是ATL，MFC以及LINUX中使用得比較多的非常重要的技巧。?
##?連接符與#?符
##?連接符號由兩個井號組成，其功能是在帶參數(shù)的宏定義中將兩個子串(token)聯(lián)接起來，從而形成一個新的子串。但它不可以是第一個或者最后一個子串。所謂的子串(token)就是指編譯器能夠識別的最小語法單元。具體的定義在編譯原理里有詳盡的解釋，但不知道也無所謂。同時值得注意的是#符是把傳遞過來的參數(shù)當(dāng)成字符串進(jìn)行替代。下面來看看它們是怎樣工作的。這是MSDN上的一個例子。
假設(shè)程序中已經(jīng)定義了這樣一個帶參數(shù)的宏：
#define?paster(?n?)?printf(?"token"?#n?"?=?%d",?token##n?)
同時又定義了一個整形變量：
int?token9?=?9;
現(xiàn)在在主程序中以下面的方式調(diào)用這個宏：
paster(?9?);
那么在編譯時，上面的這句話被擴(kuò)展為：
printf(?"token"?"9"?"?=?%d",?token9?);
注意到在這個例子中，paster(9);中的這個”9”被原封不動的當(dāng)成了一個字符串，與”token”連接在了一起，從而成為了token9。而#n也被”9”所替代。
可想而知，上面程序運行的結(jié)果就是在屏幕上打印出token9=9
在ATL的編程中，我們查看它的源代碼就會經(jīng)常看見這樣的一段：
#define?IMPLEMENTS_INTERFACE(Itf)?{&IID_##Itf,?ENTRY_IS_OFFSET,BASE_OFFSET(_ITCls,?Itf)?},
我們經(jīng)常不假思索的這樣使用它：
……
IMPLEMENTS_INTERFACE(ICat)
……
實際上IID_ICat?已經(jīng)在別的地方由ATL向?qū)Фx了。當(dāng)沒有向?qū)У臅r候，你只要遵循把IID_加在你的接口名前面來定義GUID的規(guī)則就也可以使用這個宏。在實際的開發(fā)過程中可能很少用到這種技巧，但是ATL使用得如此廣泛，而其中又出現(xiàn)了不少這樣的源代碼，所以明白它是怎么一回事也是相當(dāng)重要的。我的一個朋友就是因為不知道IMPLEMENTS_INTERFACE宏是怎么定義的，而又不小心改動了IID_ICat的定義而忙活了一整天。
Linux的怪圈
在剛開始閱讀Linux的時候有一個小小的宏讓我百思不得其解：
#define?wait_event(wq,condition)?do{?if(condition)?break;?__wait_event(wq,condition);?}while(0)
這是一個奇怪的循環(huán)，它根本就只會運行一次，為什么不去掉外面的do{..}while結(jié)構(gòu)呢？我曾一度在心里把它叫做“怪圈”。原來這也是非常巧妙的技巧。在工程中可能經(jīng)常會引起麻煩，而上面的定義能夠保證這些麻煩不會出現(xiàn)。下面是解釋：
假設(shè)有這樣一個宏定義
#define?macro(condition)?
if(condition)?dosomething();
現(xiàn)在在程序中這樣使用這個宏：
if(temp)
macro(i);
else
doanotherthing();
一切看起來很正常，但是仔細(xì)想想。這個宏會展開成：
if(temp)
if(condition)?dosomething();
else
doanotherthing();
這時的else不是與第一個if語句匹配，而是錯誤的與第二個if語句進(jìn)行了匹配，編譯通過了，但是運行的結(jié)果一定是錯誤的。
為了避免這個錯誤，我們使用do{….}while(0)?把它包裹起來，成為一個獨立的語法單元，從而不會與上下文發(fā)生混淆。同時因為絕大多數(shù)的編譯器都能夠識別do{…}while(0)這種無用的循環(huán)并進(jìn)行優(yōu)化，所以使用這種方法也不會導(dǎo)致程序的性能降低。
幾個小小的警告
正如微軟聲稱的一樣，宏定義與預(yù)編譯器指令是強(qiáng)大的，但是它又使得程序難以調(diào)試。所以在定義宏的時候不要節(jié)省你的字符串，一定要力爭完整的描述這個宏的功能。同時在定義宏的時候如有必要（比方使用了if語句）就要使用do{…}while(0)將它封閉起來。在宏定義的時候一定要注意各個宏之間的相互依賴關(guān)系，盡量避免這種依賴關(guān)系的存在。下面就有這樣一個例子。
設(shè)有一個靜態(tài)數(shù)組組成的整型隊列，在定義中使用了這樣的方法：?int?array[]={5,?6,?7,?8};
我們還需要在程序中遍歷這個數(shù)組。通常的做法是使用一個宏定義
#define?ELE_NUM?4
…………………………..
……………………………..
for(int?I=0;I<ELE_NUM;I++)
{
cout<<array[I];
}
由于某種偶然的原因，我們刪除了定義中的一個元素，使它變成：
array[]={5,6,7}
而卻忘了修改ELE_NUM的值。那么在上面的代碼中馬上就會發(fā)生訪問異常，程序崩潰。然后是徹夜不眠的調(diào)試，最后發(fā)現(xiàn)問題出在這個宏定義上。解決這個問題的方法是不使用
array[]={….}這樣的定義，而顯式的申明數(shù)組的大小：
array[ELE_NUM]={….}
這樣在改動數(shù)組定義的時候，我們就不會不記得去改宏定義了。總之，就是在使用宏定義的時候能夠用宏定義的地方統(tǒng)統(tǒng)都用上。
我發(fā)現(xiàn)的另一個有趣的現(xiàn)象是這樣的：
假設(shè)現(xiàn)在有一個課程管理系統(tǒng)，學(xué)生的人數(shù)用宏定義為：
#define?STU_NUM?50
而老師的人數(shù)恰好也是50人，于是很多人把所有涉及到老師人數(shù)的地方通通用上STU_NUM這個宏。另一個學(xué)期過去，學(xué)生中的一個被開除了，系統(tǒng)需要改變。怎么辦呢？簡單的使用#define?STU_NUM?49?么？如果是這樣，一個老師也就被開除了，我們不得不手工在程序中去找那些STU_NUM宏然后判斷它是否是表示學(xué)生的數(shù)目，如果是，就把它改成49。天哪，這個宏定義制造的麻煩比使用它帶來的方便還多。正確的方法應(yīng)該是為老師的數(shù)目另外定義一個宏：
#define?TEA_NUM?50
當(dāng)學(xué)生的數(shù)目改變以后只要把STU_NUM?定義為49就完成了系統(tǒng)的更改。所以，當(dāng)程序中的兩個量之間沒有必然聯(lián)系的時候一定不要用其中的一個宏去替代另一個，那只會讓你的程序根本無法改動。
最后，建議C/C++語言的初學(xué)者盡可能多的在你的程序中使用宏定義和預(yù)編譯指令。多看看MFC，ATL或者LINUX的源代碼，你會發(fā)現(xiàn)C語言強(qiáng)大的原因所在。