//TITLE:
// 如何写优雅的代码(2)——#define?const?还是enum?
//AUTHOR:
// norains
//DATE:
// Tuesday 21-July-2009
//Environment:
// WINCE5.0 + VS2005
//========================================================================
#define,const,enum:这三者有何关联?一个是宏定义,一个是静态修饰符,最后一个还是枚举类型。是不是有点像养麦皮打浆糊——粘不到一起?如果我们将范围缩小再缩小,让三者都只局限于“固定值”,那么千丝万缕的关系就了然于纸上——至少,有共同点了。
在解释什么是“固定值”之前,我们先来了解何为“奇数”。太多的原则都有告诫,少用“奇数”,因为这将导致代码不可维护。听起来似乎如算命的释语般玄之又玄,不可捉摸,但其间的语义却是如此简单。下面这两个代码段,正好说明“奇数”之糟糕:
- 代码段1:
- switch(mode)
- {
- case 1:
- //TO Do someting.
- break;
- case 2:
- //TO Do someting.
- break;
- case 3:
- //TO Do someting.
- break;
- }
- 代码段2:
- switch(mode)
- {
- case SLEEP:
- //TO Do someting.
- break;
- case POWER_OFF:
- //TO Do someting.
- break;
- case POWER_ON:
- //TO Do someting.
- break;
- }
显而易见,代码段2的可读性比代码段1要高多了。在这两个实例里,像“1”,“2”,“3”这种就叫奇数,而“SLEEP”,“POWER_OFF”,“POWER_ON”就是固定值。固定值的定义在C++中有三种方式,分别就是本文要讨论的#define,const和enum。
大名鼎鼎的《Effect C++》的作者Scott Meyers就曾建议过,凡是用const能代替#define的地方,都应该用const。这句话不无道理,也从另一方面来说,#define和const事实上很多地方都能互用。
比如:
- const DWORD DEFAULT_VOLUME = 0xFFFF;
- //#define DEFAULT_VOLUME 0xFFFF
- ...
- m_dwVolume = DEFAULT_VOLUME;
无论你是用const还是#define来定义DEFAULT_VOLUME,对于m_dwVolume = DEFAULT_VOLUME这语句而言都没有本质性的变化。那么,是不是意味着,是用#define还是用const,完全取决于当时的心情了?答案自然是否定的,否则本文就成了抒情散文了。
#define有个致命的缺陷,不受作用域限制。凡是在#define之后的代码,都可以直接使用#define定义的数值。
我们经常会写这么一个函数,用以获取某个设备的DWORD值。但这个函数不是返回BOOL类型来表示成败,而是采用另外一种方式:当读取成功时,返回的是具体和设备有关的数值;当失败时,返回的是默认数值。听起来这函数功能有点奇怪,也怀疑在什么情况下才会采用如此设计,但可惜本文主题不是讨论该函数能干什么,或应该出现于什么地点,我们只要知道有这么一种函数即可。
我们姑且假设这函数原型如下:
- DWORD GetDevDW(HANDLE hDev,DWORD dwError);
调用也很简单:
- DWORD dwVal = GetDevDW(hDev,ERROR_VALUE);
在这个例子中,如果dwVal的数值等于ERROR_VALUE,那么意味着调用GetDevDW失败;不等于ERROR_VALUE才意味着调用成功。
现在我们有两个函数,分别用来获取两个设备的信息。在接下来的例子中,我们采用#define来定义固定值:
- void GetDev1Info()
- {
- ....
- #define ERROR_VALUE 0
- GetDevDW(NULL,ERROR_VALUE);
- ...
- }
- void GetDev2Info()
- {
- ....
- #define ERROR_VALUE 2
- GetDevDW(NULL,ERROR_VALUE);
- ...
- }
看起来一切似乎都挺好,难道不是嘛?只可惜,编译会有警告出现:'ERROR_VALUE' : macro redefinition。
问题的根源只在于#define的数值没有作用域的概念。更为糟糕的是,在GetDev2Info函数中使用的ERROR_VALUE并不是我们所期望的2,而是在GetDev1Info中定义的0。噢,我的天,再也没有比这更糟糕的事了。
为了彻底解决这个警告,我们可以在GetDev2Info函数做一些额外的工作:
- void GetDev2Info()
- {
- ....
- #ifdef ERROR_VALUE
- #undef ERROR_VALUE
- #endif
- #define ERROR_VALUE 2
- GetDevDW(NULL,ERROR_VALUE);
- ...
- }
问题解决了,警告没有了,但代码却丑陋了。
还有另一种方式,更改固定值的名称:
- void GetDev1Info()
- {
- ....
- #define DEV1_ERROR_VALUE 0
- GetDevDW(NULL,DEV1_ERROR_VALUE);
- ...
- }
- void GetDev2Info()
- {
- ....
- #define DEV2_ERROR_VALUE 2
- GetDevDW(NULL,DEV2_ERROR_VALUE);
- ...
- }
同样,问题解决了,警告没有了,并且,代码也不算丑陋。遗留的唯一问题是,如果类似函数很多的话,我们需要绞尽脑汁去给每个错误固定值选择一个唯一的名字。呃,这对于我们这些懒人而言,这并不算一个好差事。既然如此,为什么不用const呢?
- void GetDev1Info()
- {
- ...
- const DWORD ERROR_VALUE = 0;
- GetDevDW(NULL,ERROR_VALUE);
- ....
- }
- void GetDev2Info()
- {
- ...
- const DWORD ERROR_VALUE = 2;
- GetDevDW(NULL,ERROR_VALUE);
- ...
- }
没错,仅此而已。因为const DWORD声明的是一个局部变量,受限于作用域的局限,所以我们在GetDev1Info和GetDev2Info都能使用相同的固定值名称。
这个例子也许还不足以说服你用const替代#define,那么接下来的例子你应该会扭转这一观念——或许这例子你已经碰到过。
我们有两个class,分别用来控制汽车的重音和功放。这两个类都需要在头文件中定义MAX_VOLUME以供使用者调用,但很不幸的是,重音和功放的MAX_VOLUME值是不同的。
如果用#define,在头文件中我们可能这么写:
- ///
- //Bass.h
- #define MAX_VOLUME 15
- ///
- //Amplifier.h
- #define MAX_VOLUME 30
当两个头文件没有同时使用时,一切都很顺利,不是嘛?
但如果我需要同时控制着两个音量,那么我们就必须要同时include这两个文件,像这种调用大家应该不陌生吧:
- #include "Bass.h"
- #include "Amplifier.h"
那么问题就很显然:严重的警告或是无法通过编译。
为了解决这个问题,我们还是只能请出const。只不过,如果还是简单地声明如下:
- ///
- //Bass.h
- const DWORD MAX_VOLUME = 15;
- ///
- //Amplifier.h
- const DWORD MAX_VOLUME = 30;
那么该出现的问题还是和用#define一样,没有任何本质上的改变。这时候,我们只能请出namespace了。
- ///
- //Bass.h
- namespace Bass
- {
- const DWORD MAX_VOLUME = 15;
- };
- ///
- //Amplifier.h
- namespace Amplifier
- {
- const DWORD MAX_VOLUME = 30;
- }
在没有使用using来省略命名空间的情况下,我们可以这么折腾代码:
- DWORD dwBass = Bass::MAX_VOLUME;
- DWORD dwAmplifier = Amplifier::MAX_VOLUME;
在这个例子中,命名空间起到标志作用,标明当前的MAX_VOLUME属于哪种范畴,也算意外的收获。
看到这里,也许有人会问,如果是namespace + #define方式可以么?很遗憾,答案是不行。正如前面所说,#define不受限于作用域,所以简简单单的namespace无法套住#define这只猛兽。
至此,我们可以这么下定论,在不涉及到条件编译,并且只是使用固定值的前提下,我们都应该用const来替代#define。
基于这个原则,以下的讨论我们就抛开#define,只用const。
我们再回过头来看看文章最初的例子,将其封装为一个函数:
- BOOL SwitchMode(DWORD mode)
- {
- ...
- switch(mode)
- {
- case SLEEP:
- //TO Do someting.
- break;
- case POWER_OFF:
- //TO Do someting.
- break;
- case POWER_ON:
- //TO Do someting.
- break;
- }
- ...
- }
在代码的他处定义了如下固定值:
- const DWORD SLEEP = 0x00;
- const DWORD POWER_OFF = 0x02;
- const DWORD POWER_ON = 0x03;
调用的时候:
- SwitchMode(SLEEP);
- ...
- SwitchMode(POWER_OFF);
- ...
很好,很漂亮,难道不是么?
但这样子无法保证使用者不是如此调用代码:
- SwitchMode(0x100);
0x100不是我们想要的数值,在SwitchMode函数也不会对该数值有相应的处理,但偏偏这符合编译器的规范,它会让这代码没有任何警告没有任何错误顺利编译通过。
也许还有人说,谁会那么傻,直接用0x100来赋值啊?这话确实没错,直接用0x100的概率确实太少了。
但我们无法否认,会有这么一种可能:有另外一个函数,其中一个固定值为如下定义:
- const DWORD FILE_MODE = 0x100;
而我们一时冲昏了头,又或许喝醉了酒,将该参数误用了:
- SwitchMode(FILE_MODE);
对于编译器来说,无论是0x100还是FILE_MODE,都没有太多意义,所以这病态代码很容易通过编译器检测;而对于人而言,因为已经使用了固定值,也下意识以为这参数是符合的。两者,无论是编译器,还是我们,都被合理地蒙骗了。
那么,我们有办法在编译的时候,如果该数值不是我们所想要的,编译器能给使用者提示警告甚至错误么?
一切皆有可能!不过,这时候我们不能使用const,而必须换用enum。
首先用enum定义固定值:
- enum Mode
- {
- SLEEP,
- POWER_OFF,
- POWER_ON,
- };
函数的声明如此更换:
- BOOL SwitchMode(Mode mode)
调用也是和之前无异:
- SwitchMode(SLEEP);
- ...
- SwitchMode(POWER_OFF);
- ...
唯一的不同就是,如果你这样调用:
- SwitchMode(0x100); //这时候无法编译通过
- SwitchMode(FILE_MODE); //这时候无法编译通过
那么编译器就会毫不犹豫地发出抱怨:cannot convert parameter 1 from 'int' to 'Mode'。
很好,编译器已经作为我们的第一道防火墙,将我们所不需要的毫无关联的数值通通排除在外。难道不是很美好吗?
当然,如果你想强制让编译器通过异样的数值也不是不可能:
- SwitchMode(static_cast<Mode>(0x100));
虽然0x100不处于Mode的范围之内,但依然还是通过了编译器的检测。对此,我们毫无办法。只是,像这种极端的异教徒的做法,有多少情况下会碰到呢?
最后的最后,我们略微总结一下:
1.只是声明单一固定值,尽可能采用const。
2.如果是一组固定值,并且互相有关联,则采用enum。
3.不涉及条件编译,只是定义固定值的情形下,尽可能不使用#define。