时间：2021-02-23 15:17:15 | 栏目：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)
编译通过了，好不容易啊！