宏不遵循C++中關(guān)于范圍和類型的規(guī)則。這經(jīng)常導(dǎo)致一些微妙的或不那么微妙的問(wèn)題。因此，C++提供更適合其他的C++（譯注：原文為the rest of C++，當(dāng)指C++除了兼容C 以外的部分）的替代品，例如內(nèi)聯(lián)函數(shù)、模板與名字空間。

考慮一下：

#include "someheader.h"
struct S {
  int alpha;
  int beta;
};

如果某人（不明智地）地寫了一個(gè)叫“alpha”或“beta”的宏，那么它將不會(huì)被編譯，或者被錯(cuò)誤地編譯，產(chǎn)生不可預(yù)知的結(jié)果。例如，“someheader.h”可能包含：

  #define alpha 'a'
  #define beta b[2]

將宏（而且僅僅是宏）全部大寫的習(xí)慣，會(huì)有所幫助，但是對(duì)于宏并沒有語(yǔ)言層次上的保護(hù)機(jī)制。例如，雖然成員的名字包含在結(jié)構(gòu)體的內(nèi)部，但這無(wú)濟(jì)于事：在編譯器能夠正確地辨別這一點(diǎn)之前，宏已經(jīng)將程序作為一個(gè)字符流進(jìn)行了處理。順便說(shuō)一句，這是C 和C++程序開發(fā)環(huán)境和工具能夠被簡(jiǎn)化的一個(gè)主要原因：人與編譯器看到的是不同的東西。

不幸的是，你不能假設(shè)別的程序員總是能夠避免這種你認(rèn)為“相當(dāng)白癡”的事情。例如，最近有人報(bào)告我，他們遇到了一個(gè)包含goto 的宏。我也見過(guò)這種情況，而且聽到過(guò)一些——在很脆弱的時(shí)候——看起來(lái)確實(shí)有理的意見。例如：

#define prefix get_ready(); int ret__
#define Return(i) ret__=i; do_something(); goto exit
#define suffix exit: cleanup(); return ret__
void f(){
  prefix;
  // ...
  Return(10);
  // ...
  Return(x++);
  //...
  suffix;
}

作為一個(gè)維護(hù)的程序員，就會(huì)產(chǎn)生這種印象；將宏“隱藏”到一個(gè)頭文件中——這并不罕見——使得這種“魔法”更難以被辨別。

一個(gè)常見的微妙問(wèn)題是，一個(gè)函數(shù)風(fēng)格的宏并不遵守函數(shù)參數(shù)傳遞的規(guī)則。例如：

#define square(x) (x*x)
void f(double d, int i){
  square(d); // 好
  square(i++); // 糟糕：這表示 (i++*i++)
  square(d+1); //糟糕：這表示(d+1*d+1); 也就是 (d+d+1)
  // ...
}

“d+1”的問(wèn)題，可以通過(guò)在“調(diào)用”時(shí)或宏定義時(shí)添加一對(duì)圓括號(hào)來(lái)解決：

  #define square(x) ((x)*(x)) /*這樣更好 */

但是， i++被執(zhí)行了兩次（可能并不是有意要這么做）的問(wèn)題仍然存在。

是的，我確實(shí)知道有些特殊的宏并不會(huì)導(dǎo)致C/C++預(yù)處理宏這樣的問(wèn)題。但是，我無(wú)心去發(fā)展C++中的宏。作為替代，我推薦使用C++語(yǔ)言中合適的工具，例如內(nèi)聯(lián)函數(shù)，模板，構(gòu)造函數(shù)（用來(lái)初始化），析構(gòu)函數(shù)（用來(lái)清除），異常（用來(lái)退出上下文環(huán)境），等等。

好了，今天就先到這里，以后我們?cè)賮?lái)更深入的探討這個(gè)問(wèn)題

最新評(píng)論