双刃剑 - 宏

                                                             转自：http://www.javaeye.com/topic/63083

在C中使用宏的确是一个非常好的代码手段，可以大量的减少代码量，提高阅读性，通过对一些常用代码的归类写成宏，作用巨大.
例如如下代码:
if(((t->flag & S_FLAG1) || (t->flay & S_FLAG2)) && t->type == T_TYPE1)
...
条件部分如果多次使用到，那么我们完全可以写如下的宏
#define IsXXXX(t) (((t->flag & S_FLAG1) || (t->flay & S_FLAG2)) && t->type == T_TYPE1)
这样上面的代码就成了
if(IsXXXX(t))
...
代码少了很多，而且可读性也增加了很多.
还有一个代码，C中分配一个结构，一般如下代码:
p=(STRUCT*)malloc(sizeof(STRUCT));
是否可以更加漂亮呢？创建一个宏，如下:
#define new(t) (t*)malloc(t)
这样上面的代码就变成了
p=new(STRUCT);
是否有C++的风格了？

但是有利必有弊，宏一旦使用不当反而会产生严重的后遗症,下面随意说几点.
1.给宏赋予太强大的功能，几乎所有的编译器以及大部分的IDE无法展开和定位宏中的代码，所以一旦产生错误，很难调试, 如果真的需要最好还是用函数来封装.

2.宏名字起的不当，这是很致命的，会导致代码可读性大大降低，例如随意将前面例子中的IsXXXX定义为a，然后后面的代码中全是一堆的
if(a(t))
如果这样，键盘是少打了，但是已经完全没有了可读性，也许今天写的这个宏，明天你就忘记这个宏是做什么了. 同时过于简单的名字也会导致同名但是功能不同的宏大量出现，使得代码更难看懂.

3.宏的随意undef，这个是一个很不好的习惯，代码量一旦达到了一定程度，会导致极度的混乱.
例如在某个.h文件中定义了IsXXXX，然后在某个.c中如下使用
#undef IsXXXX
#define IsXXXX(t) (((t->flag & S_FLAG3) || (t->flay & S_FLAG4)) && t->type == T_TYPE2)
这个对于以后的维护修改埋下了极大的隐患.

4.重名，说起来这个算是很多编译器的问题，如果将一个宏的名字和一个变量的名字重名了，那么很多的C Compiler默认状态下不会报警或报错.
例如:
int a;
...
#define a b
这种错误有时候简直可以让人发疯！！！

5.宏的嵌套使用，不是不能这么用，由于宏屏蔽了实际代码，如果宏->宏，那么即使你的宏写的够漂亮明了，恐怕天长日久也就忘记里面具体的逻辑，一旦想修改就很麻烦，所以要小心使用.

到了C++年代，宏的使用少了很多，不过模板几乎就是宏的升级.
说起来在MFC中消息映射就是一套极具特色的宏，如果不了解它也就算了，但是当你看懂了就会感叹宏的魔力！