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