c++ 預處理的圖靈完備之引言

我們還是來討論c++吧，這幾年在c++里面玩代碼自動生成技術，而預處理是不可避免，也是不可或缺的重要工具。雖然boost pp預處理庫在宏的運用上很是完善，但是代碼也太多了，而且代碼很不好理解，對此，不免讓人疑惑，有必要搞得那么復雜，搞那么多代碼嗎？并且，看了boostpp的使用接口后，感覺寫得很不干凈，也不好組合。因此，重新做了一套預處理的輪子。以下的代碼，假設在msvc2013以上的版本運行，反正很多人用MSVC的，裝逼的自當別論，造出來的輪子，傾向于先支持msvc。

首先，我們定義一個宏，用來給把入參變成字符串，咦，這個事情也太easy了，但是，在此，感覺，還是有必要廢話多解釋一下。以下代碼慣例都是，所有可用的宏函數都是以PP開頭全部大寫，而以_ZPP開頭的全部都是內部實現，其實還可以做得更難看一點。因為宏函數是全局的，沒有作用域的概念，并且只是單純的文本替換，死的時候，還不知道怎么死，所以，必須謹慎對待。像是windows.h頭文件那樣，直接用min，max作為宏的名字，雖然用起來很方便，但也不知道制造了多少麻煩，所以，很多時候，包含windows.h時，第一件事情就是undef min和max。

以下的代碼，可以隨便在某個工程下，隨便建立一個cpp后綴名的源文件，然后按CTRL+F7編譯，不需要F5，就可以看到運行的效果，如果編譯通過，就說明宏基本上正確，測試代碼越多，準確性就越高。當然，你們也可以通過設置源文件的屬性，讓msvc生成預處理后的文件，然后用記事本打開那個文件觀看。

#define PP_TEXT(str) _ZPP_TEXT(str)
#define _ZPP_TEXT(str) #str

在c++預處理宏中，操作符#是將后面跟隨的表達式加上兩個雙引號，也就是字符串。PP_TEXT(str)不是直接定義成#str，而是通過調用_ZPP_TEXT(str)，然后在那里才將入參變成字符串，顯得有點輾轉，有點多此一舉，但，其實是為了支持宏的全方位展開，也就是入參str本身也存在宏調用的時候，純屬無奈。比如，如果這樣實現

#define PP_TEXT(str) #str

那么，對于下面的情況，

#define AAA aaa

PP_TEXT(AAA)，結果將是"AAA",而不是"aaa"。因為宏操作符直接是將入參變成字符串，沒有讓入參有一點點回旋的空間，所以只好引入間接層，讓入參有機會宏展開。后面，很多宏函數都是這樣實現，不得不間接調用，以便讓宏全面展開。而msvc的宏展開機制更加奇葩，更加不人性化，其間接調用的形式也更丑陋。這都是沒辦法的事情。
然后，為了調試宏，或者測試宏，當然，很多時候，調試宏，還是要打開預處理的文件來對比分析。我們對 static_assert作一點點包裝，因為static_assert需要兩個參數，c++11后面的c++版本中，static_assert好像只需要一個入參，那時就不需要這個包裝了。

#define PP_ASSERT() static_assert((__VA_ARGS__), PP_TEXT(__VA_ARGS__));

PP_ASSERT(...)里面的三個點，是不定參數的宏，而__VA_ARGS__就代表了...所匹配的所有參數，這條語法很重要，要熟練。這里，就不詳細解釋其用法了，后面會有大把大把的宏函數用到__VA_ARGS__。
好了，我們可以開始用PP_ASSERT(...)做測試了。
PP_ASSERT(2+3==5)
如果，然后編譯這個文件，發現編譯通過了，比如
PP_ASSERT(2+3==4)
編譯的時候，就會報錯誤信息，error C2338: 2+3==4
好了，測試準備建立起來，就可以開始肆無忌憚的寫代碼了。一步一步地構建c預處理宏的圖靈完備。
顯然，當務之急，最根本的宏就是將兩個宏參數的并接，也即是##運算符，顯然好比#運算那樣子，必須給里面參數有宏展開的機會，因此要間接調用，下面是其實現

#define PP_JOIN(_A, _B) _ZPP_JOIN_I(_A, _B)
#define _ZPP_JOIN_I(_A, _B) _ZPP_JOIN_II(~, _A##_B)
#define _ZPP_JOIN_II(p, res) res

竟然不止一層間接，而是兩層，又多此一舉，是因為發現在做宏遞歸的時候，一層間接調用還不能讓宏充分地展開，所以只好又加間接層，也不明白是何原因，也懶得追究了。現在，接下來，當然是測試PP_JOIN了。各位同學，可以新建立一個測試文件，那個文件include我們的這個宏函數。當然，也可以在同一個文件里面寫測試代碼，注意分成兩段代碼，上一段寫宏函數，下一段寫測試代碼，目前來看，都可以的，后面再整理。

PP_ASSERT(PP_JOIN(1+2, == 3))
#define A 20
#define B 10
PP_ASSERT(PP_JOIN(A + B, == 30))

有了PP_JOIN，就可以開始做點其他事情了。比如，計數器，

#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

這里，我們重新又實現了一遍PP_JOIN，這也是沒辦法的事情，后面在重重嵌套的時候，會出現PP_JOIN里面又包含PP_JOIN的情況，這樣會導致宏停止展開了，所以，只好對于每一個要用到JOIN之處，都用自己版本的JOIN。
這是宏函數的實現方式，通過并接，文本替換，一一枚舉，才達到這樣的效果，也就是說，我們通過JOIN函數，在宏里面構造了一個計數器的數據類型。如果每個宏函數都這樣寫，豈不是很累。好消息是，只需用這種苦逼方式實現幾個最基本的函數，然后通過宏的遞歸引擎，其他的宏函數就不需這樣子一個一個苦逼的并接替換了。
PP_ASSERT(PP_INC(9)==10)
PP_ASSERT(PP_INC(PP_INC(9)) == 11)
寫測試代碼習慣了，寫起來就很有意思了，測試通過，也是最激動人心的時刻。
接下來，要處理msvc里面宏的惡心行為，然后就結束本引言。

#define PAIR_SECOND(x, y) y
PP_ASSERT(PAIR_SECOND(10, 20) == 20)

這樣子，還不錯，下面，再define一個宏函數，讓其返回一個pair，也就是兩個值

#define MAKE_PAIR(x, y) x, y

然后，這樣調用，
PAIR_SECOND(MAKE_PAIR(10, 20))
編譯器馬上就不高興了，warning C4003: “PAIR_SECOND”宏的實參不足
好像是編譯器沒有先展開MAKE_PAIR(10, 20)，然后再調用PAIR_SECOND，而是直接把MAKE_PAIR(10, 20)整個當成一個函數傳給PAIR_SECOND，然后，PAIR_SECOND就提示實參不足，然后，硬要測試，
PP_ASSERT(PAIR_SECOND(MAKE_PAIR(10, 20)) == 20)
顯然，無論如何，編譯器勢必就龍顏大怒了。對此，我們只好再引入間接層，想辦法讓MAKE_PAIR(10, 20)先展開，然后再傳給PAIR_SECOND。這樣，就不能直接用這樣的形式了，PAIR_SECOND(MAKE_PAIR(10, 20)) 。只好改成這樣，下面的幾行代碼，很有點驚天地泣鬼神的味道。

#define _ZPP_INVOKE_JOIN(_A, _B) _ZPP_IMP_INVOKE_JOIN_I(_A, _B)
#define _ZPP_IMP_INVOKE_JOIN_I(_A, _B) _ZPP_IMP_INVOKE_JOIN_II(~, _A##_B)
#define _ZPP_IMP_INVOKE_JOIN_II(p, res) res

#define PP_INVOKE(m, args, ) _ZPP_INVOKE_JOIN(m, args) 

前面幾行代碼都是PP_INVOKE的JOIN函數實現，可以直接當它們是JOIN函數，關鍵是PP_INVOKE(m, args, ...)這里，第一個參數m是宏函數，第二個是args，是要傳給第一個參數m的參數列表，用括號括起來，至于后面的省略號，是有些時候為了取悅編譯器而添加的，也不知道是什么原因，反正這樣子就可以了，懶得追究。垃圾宏，垃圾預處理，只要能完成功能就行了，c++中，代碼生成代碼，重頭戲在tmp那里，宏只是小小必要的輔助工具而已。然后，這樣調用，
PP_ASSERT(PP_INVOKE(PAIR_SECOND, (MAKE_PAIR(10, 20))) == 20)
編譯通過了，好不容易啊！