我们还是来讨论c++吧,这几年在c++里面玩代码自动生成技术,而预处理是不可避免,也是不可或缺的重要工具。虽然提高pp预处理库在宏的运用上很是完善,但是代码也太多了,而且代码很不好理解,对此,不免让人疑惑,有必要搞得那么复杂,搞那么多代码吗?并且,看了boostpp的使用接口后,感觉写得很不干净,也不好组合,因此,重新做了一套预处理的轮子。以下的代码,假设在msvc2013以上的版本运行,反正很多人用MSVC的,装逼的自当别论,造出来的轮子,倾向于先支持MSVC。
首先,我们定义一个宏,用来给把入参变成字符串,咦,这个事情也太容易了,但是,在此,感觉,还是有必要废话多解释一下。以下代码惯例都是,所有可用的宏函数都是以PP开头全部大写,而以_ZPP开头的全部都是内部实现,其实还可以做得更难看一点。因为宏函数是全局的,没有作用域的概念,并且只是单纯的文本替换,死的时候,还不知道怎么死,所以,必须谨慎对待。像是windows.h头文件那样,直接用最小值,最大值作为宏的名字,虽然用起来很方便,但也不知道制造了多少麻烦,所以,很多时候,包含窗口。h时,第一件事情就是undef min和max。
以下的代码,可以随便在某个工程下,随便建立一个cpp后缀名的源文件,然后按CTRL + F7编译,不需要F5,就可以看到运行的效果,如果编译通过,就说明宏基本上正确,测试代码越多,准确性就越高。当然,你们也可以通过设置源文件的属性,让msvc生成预处理后的文件,然后用记事本打开那个文件观看。
在c++预处理宏中,操作符#是将后面跟随的表达式加上两个双引号,也就是字符串.PP_TEXT (str)不是直接定义成# str,而是通过调用_ZPP_TEXT (str),然后在那里才将入参变成字符串,显得有点辗转,有点多此一举,但,其实是为了支持宏的全方位展开,也就是入参str本身也存在宏调用的时候,纯属无奈。比如,如果这样实现
那么,对于下面的情况,
PP_TEXT (AAA),结果将是“AAA”,而不是“AAA”。因为宏操作符直接是将入参变成字符串,没有让入参有一点点回旋的空间,所以只好引入间接层,让入参有机会宏展开。后面,很多宏函数都是这样实现,不得不间接调用,以便让宏全面展开。而msvc的宏展开机制更加奇葩,更加不人性化,其间接调用的形式也更丑陋。这都是没办法的事情。
然后,为了调试宏,或者测试宏,当然,很多时候,调试宏,还是要打开预处理的文件来对比分析。我们对static_assert作一点点包装,因为static_assert需要两个参数,c++ 11后面的c++版本中,static_assert好像只需要一个入参,那时就不需要这个包装了。
PP_ASSERT(…)里面的三个点,是不定参数的宏,而__VA_ARGS__就代表了…所匹配的所有参数,这条语法很重要,要熟练。这里,就不详细解释其用法了,后面会有大把大把的宏函数用到__VA_ARGS__。
好了,我们可以开始用PP_ASSERT(…)做测试了。
PP_ASSERT (2 + 3==5)
如果,然后编译这个文件,发现编译通过了,比如
PP_ASSERT (2 + 3==4)
编译的时候,就会报错误信息,错误C2338: 2 + 3==4
好了,测试准备建立起来,就可以开始肆无忌惮的写代码了。一步一步地构建c预处理宏的图灵完备。
显然,当务之急,最根本的宏就是将两个宏参数的并接,也即是# #运算符,显然好比#运算那样子,必须给里面参数有宏展开的机会,因此要间接调用,下面是其实现
竟然不止一层间接,而是两层,又多此一举,是因为发现在做宏递归的时候,一层间接调用还不能让宏充分地展开,所以只好又加间接层,也不明白是何原因,也懒得追究了。现在,接下来,当然是测试PP_JOIN了。各位同学,可以新建立一个测试文件,那个文件包括我们的这个宏函数。当然,也可以在同一个文件里面写测试代码,注意分成两段代码,上一段写宏函数,下一段写测试代码,目前来看,都可以的,后面再整理。
