宏的一些副作用

1、优先级问题

1) 传入变量优先级

#define MULTI(a,b) a * b

MULTI(1+2,3) => 1 + 2 * 3 其实是想要(1 + 2) * 3

2) 作为值返回时,类似1)

#define ADD(a,b) (a) + (b)

int c = ADD(a,b) * 3; => (a) + (b) * 3  其实是想要(a + b) * 3

所以,一般的规则是:宏里面参数全部用括号括起来;如果作为值返回,整个表达式也用括号括起来

所以,上面最好这么写:

#define MULTI(a,b) ((a) * (b))

#define ADD(a,b) ((a) + (b))

2、实际使用参数和宏内部变量同名

#define HASH(str,sz,rst) do{unsigned int n = 0; n = xxx; rst = n % sz;}while(0)

这是一个hash的宏实现,其中定义了一个临时变量n,根据str计算n,然后对sz求模并把返回值赋给传进来的rst.

这么调用:

int n;

HASH("hello",7,n);

不会达到改变n的效果,因为实际使用参数n和宏内部的变量n同名。宏扩展中最后一条语句是:n = n % sz;因为宏内部n有更小作 用域,实际赋值的是宏内部的那个临时变量n。外面调用的n不会有任何改变。

这个副作用有些隐蔽,一般的规则是:宏内部变量使用一种不同风格的命名方式。

比如:

#define HASH(str,sz,rst) do{unsigned int __n = 0; __n = ...

3、++,--

#define MAX(a,b) ((a) > (b) ? (a) : (b))

int a = 3,b = 2;

i nt c = MAX(a++,b);

执行看看,不但a的值不是和想要的一致,返回值c也会让你大吃一惊,哈哈。(a = 5,c = 4)

在宏内部一个变量"执行"多少次,它就自增或自减了多少次。

所以一般使用宏最好不要传入自增自减 。如果你一定要在宏里消除这个副作用,可以这样:

#define MAX(a,b) ({int __x = (a), __y = (b);(__x > __y) ? __x : __y;})

也就是:保证传入宏的参数在内部只使用一次。(注意:传入a++或++a都能得到各自正确的效果)

这里的内部变量__x,__y是不需要用括号包起来的,原因可以自己想想。

另外对宏中括号的使用补充说明两点:

因为宏中定义了临时变量,所以要用{}括起来;

因为要返回值,所以外面还要用()括起来({}不返回值);

另外,这里还有一个问题:实际中a,b不一定是int的,这个宏中的临时变量声明为int,不通用。

改进:

#define MAX(a,b,type) ({type __x = (a), __y = (b);(__x > __y) ? __x : __y;})

使用:

MAX(1,2,int);  MAX(1.1,1.2,double);

是不是感觉怪怪的,有点c++的感觉~~ 这样的使用太复杂了,而且也会给代码的阅读带来难度。

 

我觉得好的态度是多了解些宏的可能的副作用,在实际编码中遵守第1、2条规则,不要往宏中传入自增自减的东西,就够了。不要把过多的复杂度全扔给宏,"通用"也不能盲目,因为毕竟:yy是没有极限的。

 

补充:

   今天看到有人用typeof,很好的解决了上面的问题。

  • 0
    点赞
  • 17
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值