Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1814091
  • 博文数量: 241
  • 博客积分: 9862
  • 博客等级: 中将
  • 技术积分: 5206
  • 用 户 组: 普通用户
  • 注册时间: 2005-02-18 23:23
文章分类
文章存档

2011年(14)

2010年(61)

2009年(48)

2008年(118)

我的朋友

分类: C/C++

2010-06-29 13:45:30


以下一段代码来自于linux中的pthread.h
  1. enum
  2. {
  3.   PTHREAD_CANCEL_ENABLE,
  4. #define PTHREAD_CANCEL_ENABLE   PTHREAD_CANCEL_ENABLE
  5.   PTHREAD_CANCEL_DISABLE
  6. #define PTHREAD_CANCEL_DISABLE  PTHREAD_CANCEL_DISABLE
  7. };

一直想不明白此处将#define放入enum有何意义?在进行一遍预处理后,也没看出此处的#define有何用处。哪位有心得,讲讲!
 

以前的版本中 PTHREAD_CANCEL_ENABLE 和 PTHREAD_CANCEL_DISABLE 都是定义为以下宏的形式:
  1. #define PTHREAD_CANCEL_ENABLE           0x00
  2. #define PTHREAD_CANCEL_DISABLE          0x01

由于宏属于编译预处理,不属于语言本身,所以在编译预处理阶段只是进行简单的字串替换,不进行语法检查;宏在使用上还有一些固有的缺陷需要特别注意;宏名也不会增添到目标文件的符号列表中,因而不利于程序的调试,等等。

以上种种,在现代的 C 或者 C++ 语言中应该尽量避免使用宏、而是用 const、enum 或 inline (指对函数而言)等来代替,这已经是人们的共识。

楼主给出的代码反映的就是由原来的宏定义修改为枚举(enum)定义后的情况。由于 PTHREAD_CANCEL_ENABLE 和 PTHREAD_CANCEL_DISABLE 原来是宏定义,因此用户也可能把它们当作条件编译中的条件来使用,如:
  1. #ifdef PTHREAD_CANCEL_ENABLE
  2. /* ... */
  3. #endif

所以,PTHREAD_CANCEL_ENABLE 和 PTHREAD_CANCEL_DISABLE 作为宏定义最好应该还存在,但是它们却不能再分别代表 0 和 1 了(否则编译预处理后就被替换为 0 或 1 ,这样作为枚举常量的它们实际上就没有用武之地了),因此就在enum的定义中夹杂出现了如下“奇怪”的宏定义:
  1. enum
  2. {
  3.   PTHREAD_CANCEL_ENABLE,
  4. #define PTHREAD_CANCEL_ENABLE   PTHREAD_CANCEL_ENABLE
  5.   PTHREAD_CANCEL_DISABLE
  6. #define PTHREAD_CANCEL_DISABLE  PTHREAD_CANCEL_DISABLE
  7. };

这样定义的宏实现的是自己替换自己的功能,所以对于以后出现的 PTHREAD_CANCEL_ENABLE 或 PTHREAD_CANCEL_DISABLE 实际上没有任何影响,但是却使 PTHREAD_CANCEL_ENABLE 和 PTHREAD_CANCEL_DISABLE 两个宏有了定义,可以作为条件编译中的条件来使用。这样就将因程序修改(将宏用enum代替)而带来的影响降到了最低,是一种几乎完全的替代方案。
阅读(2616) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~