雖然通過一系列的奇技淫巧，讓預(yù)處理也圖靈完備一把，但是用預(yù)處理來做計(jì)算，真的很吃力不討好。因?yàn)轭A(yù)處理一開始設(shè)計(jì)出來的目的，就沒什么野心，原本就僅僅只是為了做簡(jiǎn)簡(jiǎn)單單的文本替換工作，并沒有想過要成為正兒八經(jīng)的編程語言，即便是最最縮水版腳本語言的功能要求都達(dá)不到。只是后來，實(shí)在是大量要求要批量自動(dòng)生成代碼，特別是c++11之前的版本玩什么模板元編程，鋪天蓋地的要有大量相似的代碼。這些代碼用其他工具來生成，當(dāng)然形式會(huì)更加漂亮，但是始終還是用原生的預(yù)處理來做這種事情會(huì)更加的方便，否則每次修改，都要運(yùn)行一遍外部工具，都麻煩??！本人是傾向于用預(yù)處理來生成代碼的。另外，c++11之后，的確原來很多需要宏來生成代碼的場(chǎng)合已經(jīng)不必要了，但是因?yàn)閏++11的類型推導(dǎo)能力大大加強(qiáng)了之后，發(fā)現(xiàn)又有一大波地方可以用宏來生成代碼了。并不是說C++中的宏是必不可少之物，但是用了宏，真的可以減少很多很多的重復(fù)代碼，起碼紙面上的代碼清爽了很多。

預(yù)處理的原生數(shù)據(jù)類型就只有符號(hào)，然后符號(hào)只支持##的并接運(yùn)算，同時(shí)，預(yù)處理也能識(shí)別并接后的結(jié)果（否則，并接運(yùn)算就沒意義了），如果是宏函數(shù)，就進(jìn)行調(diào)用操作，如果是宏符號(hào)，就替換文本，如果什么都不是，就什么都不做，保留符號(hào)。但是這樣的弱雞類型，顯然遠(yuǎn)遠(yuǎn)不能滿足離經(jīng)叛道的碼猿需要。經(jīng)過大量的宏編程的嘗試之后，可以很肯定一點(diǎn)，預(yù)處理里面只能再模擬出來一種數(shù)據(jù)類型，那就是正整數(shù)，雖然通過補(bǔ)碼運(yùn)算來仿真負(fù)數(shù)，但是由于預(yù)處理里面的符號(hào)不能包含減號(hào)(-)字符，當(dāng)然要花大力氣搗鼓負(fù)整數(shù)也是可以的，只是使用上也不方便也不直觀，性價(jià)比不高，基本上，必須用宏來生成代碼的地方，都可以不需要負(fù)整數(shù)的。

另外，預(yù)處理也沒有變量類型的概念，不要說強(qiáng)類型，就連弱類型也不是，完全就是無類型。正整數(shù)類型的概念全靠碼猿人肉編譯器來維護(hù)，一個(gè)循環(huán)的宏代碼生成一般都是來來回回也不知道調(diào)用了多少層宏調(diào)用，任何一個(gè)地方出錯(cuò)，有時(shí)候是幾噸密密麻麻的中間失敗代碼（編譯器的預(yù)處理緩沖溢出，棄械投降），有時(shí)候就完全沒有輸出，沒有任何一丁點(diǎn)的提示，簡(jiǎn)直是大海撈針的找問題。因此，在用宏循環(huán)生成代碼時(shí)，必須小心翼翼，步步為營，不得不感慨，正兒八經(jīng)語言里面的類型真是好東西啊。

其實(shí)，數(shù)據(jù)類型并不重要，重要的是數(shù)據(jù)上能夠支持的運(yùn)算集合以及這些運(yùn)算能運(yùn)用的場(chǎng)合。
好了，回到上文，我們用_ZPP_INC_N搞了10個(gè)數(shù)，通過復(fù)制粘貼，可以把N增加到255。實(shí)際運(yùn)用中，完全足夠用了。

#define _ZPP_INC_JOIN(_A, _B) _ZPP_INC_JOIN_IMP1(_A, _B)
#define _ZPP_INC_JOIN_IMP1(_A, _B) _ZPP_INC_JOIN_IMP2(~, _A##_B)
#define _ZPP_INC_JOIN_IMP2(p, res) res

#define PP_INC(x, ) _ZPP_INC_JOIN(_ZPP_INC_, x)
#define _ZPP_INC_0 1
#define _ZPP_INC_1 2
#define _ZPP_INC_2 3
#define _ZPP_INC_3 4
#define _ZPP_INC_4 5
#define _ZPP_INC_5 6
#define _ZPP_INC_6 7
#define _ZPP_INC_7 8
#define _ZPP_INC_8 9
#define _ZPP_INC_9 10
...
#define _ZPP_INC_255 256

同樣的方式，再如法泡制PP_DEC，從256開始，一直遞減到0為止。對(duì)于大于256的數(shù)，就不支持了，那就都是未定義操作。這樣子，通過PP_INC(n)，就得到n+1；而PP_DEC(n)，則是n-1。比如PP_INC(PP_DEC(9))，其結(jié)果肯定是9了。很好，這樣子，在預(yù)處理中就實(shí)現(xiàn)了自然數(shù)自增1和自減1的運(yùn)算了。另外，對(duì)于大于256的數(shù)，比如512傳遞給PP_INC，就只得到一個(gè)_ZPP_INC_512的符號(hào)，完全沒有任何意義。

然后，兩個(gè)自然數(shù)是否相等的判斷，也非常重要，必須支持。但是，在此之前，要實(shí)現(xiàn)一個(gè)宏函數(shù)PP_NOT，用來判斷入?yún)⑹欠駷?。為0的話，則函數(shù)返回1，否則，就返回0。也即是：
PP_NOT(0) == 1
PP_NOT(23) == 0，或者 PP_NOT(var) == 0。
記住，預(yù)處理提供給我們的原生類型就只有符號(hào)和##并接運(yùn)算，除此之外，別無他物。好像工具太簡(jiǎn)陋，能完成目的嗎？不得不佩服有些碼猿的腦洞。以下代碼是這樣運(yùn)作的，假設(shè)PP_NOT生成以下的調(diào)用形式，先不管PP_ARG1，至于符號(hào)~，是這樣子的，可以看成普通的變量名字，它就是占位符，因?yàn)轭A(yù)處理只識(shí)別逗號(hào)(,)，和小括號(hào)，至于其他符號(hào)，完全無視，那些是C/C++編譯階段才關(guān)心的符號(hào)。
PP_NOT(0) = PP_ARG1(~, 1, 0)
PP_NOT(n) = PP_ARG1(_ZPP_NOT_n, 0)
然后，讓PP_ARG1取第二個(gè)參數(shù)（碼猿的計(jì)數(shù)是從0開始的，也即是，0即是1，1即是2），就完成任務(wù)了。至于_ZPP_NOT_n是什么鬼，那個(gè)只是中間生成的臨時(shí)符號(hào)，可以舍棄。我們只需對(duì)_ZPP_NOT_0做特別處理。因此，代碼可以這樣寫了。PP_PROBE()用以生成兩個(gè)入?yún)?br /> #define PP_PROBE() ~, 1
#define _ZPP_NOT_0 PP_PROBE()
#define PP_NOT(_X, ...) PP_IS(PP_JOIN(_ZPP_NOT_, _X))
# define PP_IS(...) PP_ARG1(__VA_ARGS__, 0)

這樣子之后，顯然PP_NOT(n)就可以變成PP_ARG1(_ZPP_NOT_n, 0)的形式了。PP_NOT不是只需一個(gè)入?yún)?？為何后面還要帶省略號(hào)，純粹是為了后面各種變態(tài)的運(yùn)用，取悅編譯器。已經(jīng)用宏來寫代碼了，就不必再遵守什么清規(guī)戒律，只要能完成任務(wù)就行了。

至于PP_ARG1的實(shí)現(xiàn)，就很簡(jiǎn)單了，如下所示，
#define PP_ARG0(_0, ...) _0
#define PP_ARG1(_0, _1, ...) _1
#define PP_ARG2(_0, _1, _2, ...) _2

然后通過兩次取反的函數(shù)，再補(bǔ)上函數(shù)PP_BOOL，如果入?yún)?gt;0，就返回1，否則返回0，類似于整型到bool的強(qiáng)制類型轉(zhuǎn)換。
#define PP_BOOL(_X, ...) PP_NOT(PP_NOT(_X))

有了這些的鋪墊之后，要比較兩個(gè)自然數(shù)是否相等，就簡(jiǎn)單了。其實(shí)沒什么神秘的，就是針對(duì)從0到255，重復(fù)256個(gè)以下形式的#define語句，
#define _ZPP_0_EQUALS_0 PP_PROBE()
#define _ZPP_1_EQUALS_1 PP_PROBE()
#define _ZPP_2_EQUALS_2 PP_PROBE()
...
#define PP_EQUALS(x, y) PP_IS(PP_CONCAT4(_ZPP_, x, _EQUALS_, y))
PP_EQUALS就是將入?yún)⒉⒔映蒧ZPP_x_EQUALS_y的形式，只要x和y相同，也即是說，它們?cè)谏厦娴谋砀裰?，那么，道理就如同PP_NOT的實(shí)現(xiàn)那樣，最后結(jié)果就是1了。其實(shí)，預(yù)處理中沒有判斷這種玩意，只有表格，只有并接，只有查表。所謂的圖靈完備，說白了，沒有玄虛的，就是建表，然后查表。對(duì)相等比較取反PP_NOT，自然就得到不相等的判斷函數(shù)。
#define PP_UN_EQUALS(x, y) PP_NOT(PP_IS(PP_CONCAT4(_ZPP_, x, _EQUALS_, y)))
再次建表，就可以得到bool運(yùn)算的函數(shù)，或與
#define PP_OR(a,b) PP_CONCAT3(_ZPP_OR_, a, b)
#define _ZPP_OR_00 0
#define _ZPP_OR_01 1
#define _ZPP_OR_10 1
#define _ZPP_OR_11 1

#define PP_AND(a,b) PP_CONCAT3(_ZPP_AND_, a, b)
#define _ZPP_AND_00 0
#define _ZPP_AND_01 0
#define _ZPP_AND_10 0
#define _ZPP_AND_11 1

再準(zhǔn)備一張表格，將字節(jié)映射到8個(gè)二進(jìn)制位。
#define _ZPP_BINARY_0 (0, 0, 0, 0, 0, 0, 0, 0)
#define _ZPP_BINARY_1 (0, 0, 0, 0, 0, 0, 0, 1)
#define _ZPP_BINARY_2 (0, 0, 0, 0, 0, 0, 1, 0)
#define _ZPP_BINARY_3 (0, 0, 0, 0, 0, 0, 1, 1)
#define _ZPP_BINARY_4 (0, 0, 0, 0, 0, 1, 0, 0)
...
然后通過模擬計(jì)算機(jī)組成原理里面的加減乘除的原理，就可以實(shí)現(xiàn)四則運(yùn)算了。對(duì)了，整個(gè)預(yù)處理庫的代碼都在壓縮包上，功能比boost的預(yù)處理庫強(qiáng)多了，但是代碼卻少了很多，也容易理解多了，所有代碼在vs下面正常運(yùn)行，其他平臺(tái)還沒有測(cè)試。代碼包：preprocessor.rar

最新評(píng)論