条件编译解决/**/注释嵌套的问题(#if 0 #endif) (哈哈,写的很搞笑啊~转载的)

 

(hplonline)2010.12.25


《C陷阱与缺陷》里面有一个例子,ex1-2,谈到了注释嵌套的问题。
不过这个excercise讲的只是怎么通过写一段代码来检验编译器,并没有给出解决的方法。
就我所看到的C/C++编译器,比较常用的应该还是不支持/**/形式嵌套的。

》》嵌套的意义

先说一下嵌套的意义吧。如果不是动那些比较大的代码,可能也没有这个需求。

比如曾经你有一些代码:
code1 ;
code2 ;
code3 ;

某天,你发现code2的功能不用了,当然,从小我们就被教育,养成了注释的好习惯:
code1 ;
/* code2 ; */
code3 ;
因为有些暂时不用的东西以后可能又会想用了,重写一遍不如直接解除注释方便。

又某天,你发现这一大段都不想要了,那么?
/*code1 ;
/* code2 ; */
code3 ; */
这样吗?可惜最常见的情况是编译器报一个错。。。
真正匹配起的是标红的两个注释。

所以,支持嵌套注释是非常有必要的。
在一个硕大的工程里面,code[1-3]可能是很长的一块,
更恶心的是,里面有很多别人写的东西,
你不会知道你的 "/*"符号会被哪里的"*/"给截止掉。

》》土办法和洋办法

我最早学会的是土办法,因为很多C++的教条都告诉我们尽量使用 "//",少用/**/。
这样至少有一个好处,就是你用/**/去包含//的时候不会有问题。
但如果要再包含一次,结果还是会被囧掉。

还有另外一个原因,就是我们可能会需要使用不能贯穿一行的注释。
int myfunc(int n /*number of elements*/, int *a /*pointer to the first element*/)
这个时候,//的用户者又跳出来了,发明一种新格式,并且写如规范:
int myfunc(
    int n, // number of elements
    int *a // pointer to the first element
) ;
这样不就解决了注释符号的选择问题,而且看起来似乎可读性还变高了。
前人很happy地把这个写入规范中,后人当然不知道,这个“可读性变高”是土办法的副作用。

其实这些之所以为土办法,是因为他们还是没有解决注释嵌套的问题。
只是在通过种种书写上的方式,来尽量降低这个局限性带来的影响。

后来,无意中看到一个洋办法,真的很洋气啊。。。
其实我们都知道可以用 #if #endif 来条件编译,自己却没想到可以做嵌套用。
比如,前面的code,直接这样就行了:
#if 0
code1 ;
/* code2 ; */
code3 ;
#endif
这两个标记当然是可以嵌套的,因为预处理器会按照if的结构去解析它。
gcc 3.4.5的gcc和g++都测试过了,可行。

现在大多不建议用宏定义常量或者函数,因为有const和inline可以使用。
顺便小节一下,用预处理命令的主要几个地方:
1、 include guards。就是 #ifndef xx #define xx  ..... #endif这个,用在头文件中。
2、 本篇提到的嵌套注释。#if 0 ... #endif
3、 debug信息的开启开关。 #ifdef _DEBUG ... #endif

至于用条件编译来解决什么跨平台的问题,我们大多数人都很少用到。

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值