#define？const？还是enum？

技术2022-05-20 43

如何写优雅的代码（2）——#define？const？还是enum？收藏 //======================================================================== //TITLE: // 如何写优雅的代码（2）——#define？const？还是enum？ //AUTHOR: // norains //DATE: // Tuesday 21-July-2009 //Environment: // WINCE5.0 + VS2005 //========================================================================

#define，const，enum：这三者有何关联？一个是宏定义，一个是静态修饰符，最后一个还是枚举类型。是不是有点像养麦皮打浆糊——粘不到一起？如果我们将范围缩小再缩小，让三者都只局限于“固定值”，那么千丝万缕的关系就了然于纸上——至少，有共同点了。在解释什么是“固定值”之前，我们先来了解何为“奇数”。太多的原则都有告诫，少用“奇数”，因为这将导致代码不可维护。听起来似乎如算命的释语般玄之又玄，不可捉摸，但其间的语义却是如此简单。下面这两个代码段，正好说明“奇数”之糟糕： view plaincopy to clipboardprint?01.代码段1: 02.switch(mode) 03.{ 04. case 1: 05. //TO Do someting. 06. break; 07. case 2: 08. //TO Do someting. 09. break; 10. case 3: 11. //TO Do someting. 12. break; 13.} 14. 15.代码段2： 16.switch(mode) 17.{ 18. case SLEEP: 19. //TO Do someting. 20. break; 21. case POWER_OFF: 22. //TO Do someting. 23. break; 24. case POWER_ON: 25. //TO Do someting. 26. break; 27.} 代码段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事实上很多地方都能互用。比如：

view plaincopy to clipboardprint?01.const DWORD DEFAULT_VOLUME = 0xFFFF; 02.//#define DEFAULT_VOLUME 0xFFFF 03. 04.... 05. 06.m_dwVolume = DEFAULT_VOLUME; 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类型来表示成败，而是采用另外一种方式：当读取成功时，返回的是具体和设备有关的数值；当失败时，返回的是默认数值。听起来这函数功能有点奇怪，也怀疑在什么情况下才会采用如此设计，但可惜本文主题不是讨论该函数能干什么，或应该出现于什么地点，我们只要知道有这么一种函数即可。我们姑且假设这函数原型如下：

view plaincopy to clipboardprint?01.DWORD GetDevDW(HANDLE hDev,DWORD dwError); DWORD GetDevDW(HANDLE hDev,DWORD dwError);

调用也很简单：

view plaincopy to clipboardprint?01.DWORD dwVal = GetDevDW(hDev,ERROR_VALUE); DWORD dwVal = GetDevDW(hDev,ERROR_VALUE);

在这个例子中，如果dwVal的数值等于ERROR_VALUE，那么意味着调用GetDevDW失败；不等于ERROR_VALUE才意味着调用成功。现在我们有两个函数，分别用来获取两个设备的信息。在接下来的例子中，我们采用#define来定义固定值：

view plaincopy to clipboardprint?01.void GetDev1Info() 02.{ 03. .... 04. 05. #define ERROR_VALUE 0 06. GetDevDW(NULL,ERROR_VALUE); 07. 08. ... 09.} 10. 11.void GetDev2Info() 12.{ 13. .... 14. 15. #define ERROR_VALUE 2 16. GetDevDW(NULL,ERROR_VALUE); 17. 18. ... 19.} 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函数做一些额外的工作：

view plaincopy to clipboardprint?01.void GetDev2Info() 02.{ 03. .... 04. 05. #ifdef ERROR_VALUE 06. #undef ERROR_VALUE 07. #endif 08. 09. #define ERROR_VALUE 2 10. GetDevDW(NULL,ERROR_VALUE); 11. 12. ... 13.} void GetDev2Info() { .... #ifdef ERROR_VALUE #undef ERROR_VALUE #endif #define ERROR_VALUE 2 GetDevDW(NULL,ERROR_VALUE); ... }

问题解决了，警告没有了，但代码却丑陋了。还有另一种方式，更改固定值的名称:

view plaincopy to clipboardprint?01.void GetDev1Info() 02.{ 03. .... 04. 05. #define DEV1_ERROR_VALUE 0 06. GetDevDW(NULL,DEV1_ERROR_VALUE); 07. 08. ... 09.} 10. 11.void GetDev2Info() 12.{ 13. .... 14. 15. #define DEV2_ERROR_VALUE 2 16. GetDevDW(NULL,DEV2_ERROR_VALUE); 17. 18. ... 19.} 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呢？

view plaincopy to clipboardprint?01.void GetDev1Info() 02.{ 03. ... 04. 05. const DWORD ERROR_VALUE = 0; 06. GetDevDW(NULL,ERROR_VALUE); 07. 08. .... 09.} 10. 11.void GetDev2Info() 12.{ 13. ... 14. 15. const DWORD ERROR_VALUE = 2; 16. GetDevDW(NULL,ERROR_VALUE); 17. 18. ... 19.} 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，在头文件中我们可能这么写：

view plaincopy to clipboardprint?01./// 02.//Bass.h 03.#define MAX_VOLUME 15 /// //Bass.h #define MAX_VOLUME 15

view plaincopy to clipboardprint?01./// 02.//Amplifier.h 03.#define MAX_VOLUME 30 /// //Amplifier.h #define MAX_VOLUME 30

当两个头文件没有同时使用时，一切都很顺利，不是嘛？但如果我需要同时控制着两个音量，那么我们就必须要同时include这两个文件，像这种调用大家应该不陌生吧：

view plaincopy to clipboardprint?01.#include "Bass.h" 02.#include "Amplifier.h" #include "Bass.h" #include "Amplifier.h"

那么问题就很显然：严重的警告或是无法通过编译。为了解决这个问题，我们还是只能请出const。只不过，如果还是简单地声明如下：

view plaincopy to clipboardprint?01./// 02.//Bass.h 03.const DWORD MAX_VOLUME = 15; /// //Bass.h const DWORD MAX_VOLUME = 15;

view plaincopy to clipboardprint?01./// 02.//Amplifier.h 03.const DWORD MAX_VOLUME = 30; /// //Amplifier.h const DWORD MAX_VOLUME = 30;

那么该出现的问题还是和用#define一样，没有任何本质上的改变。这时候，我们只能请出namespace了。

view plaincopy to clipboardprint?01./// 02.//Bass.h 03.namespace Bass 04.{ 05. const DWORD MAX_VOLUME = 15; 06.}; /// //Bass.h namespace Bass { const DWORD MAX_VOLUME = 15; };

view plaincopy to clipboardprint?01./// 02.//Amplifier.h 03.namespace Amplifier 04.{ 05. const DWORD MAX_VOLUME = 30; 06.} /// //Amplifier.h namespace Amplifier { const DWORD MAX_VOLUME = 30; }

在没有使用using来省略命名空间的情况下，我们可以这么折腾代码：

view plaincopy to clipboardprint?01.DWORD dwBass = Bass::MAX_VOLUME; 02.DWORD dwAmplifier = Amplifier::MAX_VOLUME; DWORD dwBass = Bass::MAX_VOLUME; DWORD dwAmplifier = Amplifier::MAX_VOLUME;

在这个例子中，命名空间起到标志作用，标明当前的MAX_VOLUME属于哪种范畴，也算意外的收获。看到这里，也许有人会问，如果是namespace + #define方式可以么？很遗憾，答案是不行。正如前面所说，#define不受限于作用域，所以简简单单的namespace无法套住#define这只猛兽。至此，我们可以这么下定论，在不涉及到条件编译，并且只是使用固定值的前提下，我们都应该用const来替代#define。基于这个原则，以下的讨论我们就抛开#define，只用const。我们再回过头来看看文章最初的例子，将其封装为一个函数：

view plaincopy to clipboardprint?01.BOOL SwitchMode(DWORD mode) 02.{ 03. ... 04. 05. switch(mode) 06. { 07. case SLEEP: 08. //TO Do someting. 09. break; 10. case POWER_OFF: 11. //TO Do someting. 12. break; 13. case POWER_ON: 14. //TO Do someting. 15. break; 16. } 17. 18. ... 19.} 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; } ... }

在代码的他处定义了如下固定值：

view plaincopy to clipboardprint?01.const DWORD SLEEP = 0x00; 02.const DWORD POWER_OFF = 0x02; 03.const DWORD POWER_ON = 0x03; const DWORD SLEEP = 0x00; const DWORD POWER_OFF = 0x02; const DWORD POWER_ON = 0x03;

调用的时候：

view plaincopy to clipboardprint?01.SwitchMode(SLEEP); 02. 03.... 04. 05.SwitchMode(POWER_OFF); 06. 07.... SwitchMode(SLEEP); ... SwitchMode(POWER_OFF); ...

很好，很漂亮，难道不是么？但这样子无法保证使用者不是如此调用代码：

view plaincopy to clipboardprint?01.SwitchMode(0x100); SwitchMode(0x100);

0x100不是我们想要的数值，在SwitchMode函数也不会对该数值有相应的处理，但偏偏这符合编译器的规范，它会让这代码没有任何警告没有任何错误顺利编译通过。也许还有人说，谁会那么傻，直接用0x100来赋值啊？这话确实没错，直接用0x100的概率确实太少了。但我们无法否认，会有这么一种可能：有另外一个函数，其中一个固定值为如下定义：

view plaincopy to clipboardprint?01.const DWORD FILE_MODE = 0x100; const DWORD FILE_MODE = 0x100;

而我们一时冲昏了头，又或许喝醉了酒，将该参数误用了：

view plaincopy to clipboardprint?01.SwitchMode(FILE_MODE); SwitchMode(FILE_MODE);

对于编译器来说，无论是0x100还是FILE_MODE，都没有太多意义，所以这病态代码很容易通过编译器检测；而对于人而言，因为已经使用了固定值，也下意识以为这参数是符合的。两者，无论是编译器，还是我们，都被合理地蒙骗了。那么，我们有办法在编译的时候，如果该数值不是我们所想要的，编译器能给使用者提示警告甚至错误么？一切皆有可能！不过，这时候我们不能使用const，而必须换用enum。首先用enum定义固定值：

view plaincopy to clipboardprint?01.enum Mode 02.{ 03. SLEEP, 04. POWER_OFF, 05. POWER_ON, 06.}; enum Mode { SLEEP, POWER_OFF, POWER_ON, };

函数的声明如此更换：

view plaincopy to clipboardprint?01.BOOL SwitchMode(Mode mode) BOOL SwitchMode(Mode mode)

调用也是和之前无异：

view plaincopy to clipboardprint?01.SwitchMode(SLEEP); 02. 03.... 04. 05.SwitchMode(POWER_OFF); 06. 07.... SwitchMode(SLEEP); ... SwitchMode(POWER_OFF); ...

唯一的不同就是，如果你这样调用：

view plaincopy to clipboardprint?01.SwitchMode(0x100); //这时候无法编译通过 02.SwitchMode(FILE_MODE); //这时候无法编译通过 SwitchMode(0x100); //这时候无法编译通过 SwitchMode(FILE_MODE); //这时候无法编译通过

那么编译器就会毫不犹豫地发出抱怨：cannot convert parameter 1 from 'int' to 'Mode'。很好，编译器已经作为我们的第一道防火墙，将我们所不需要的毫无关联的数值通通排除在外。难道不是很美好吗？当然，如果你想强制让编译器通过异样的数值也不是不可能：

view plaincopy to clipboardprint?01.SwitchMode(static_cast<Mode>(0x100)); SwitchMode(static_cast<Mode>(0x100));

虽然0x100不处于Mode的范围之内，但依然还是通过了编译器的检测。对此，我们毫无办法。只是，像这种极端的异教徒的做法，有多少情况下会碰到呢？最后的最后，我们略微总结一下： 1.只是声明单一固定值，尽可能采用const。 2.如果是一组固定值，并且互相有关联，则采用enum。 3.不涉及条件编译，只是定义固定值的情形下，尽可能不使用#define。

本文来自博客，转载请标明出处：http://blog.csdn.net/norains/archive/2009/07/21/4366530.aspx

专利

最新回复(0)