#define、const和enum

#define、const还是enum
转载自:http://blog.youkuaiyun.com/norains/archive/2009/07/21/4366530.aspx

    #define,const,enum:这三者有何关联?一个是宏定义,一个是静态修饰符,最后一个还是枚举类型。是不是有点像养麦皮打浆糊——粘不到一 起?如果我们将范围缩小再缩小,让三者都只局限于“固定值”,那么千丝万缕的关系就了然于纸上——至少,有共同点了。

在解释什么是“固定值”之前,我们先来了解何为“奇数”。太多的原则都有告诫,少用“奇数”,因为这将导致代码不可维护。听起来似乎如算命的释语般玄之又玄,不可捉摸,但其间的语义却是如此简单。下面这两个代码段,正好说明“奇数”之糟糕:

  1. 代码段1:      
  2. switch(mode)  
  3. {  
  4.   case 1:  
  5.    //TO Do someting.  
  6.    break;         
  7.   case 2:  
  8.    //TO Do someting.  
  9.    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事实上很多地方都能互用。

比如

  1. const DWORD DEFAULT_VOLUME = 0xFFFF;  
  2. //#define DEFAULT_VOLUME    0xFFFF  
  3.   
  4. ...  
  5.   
  6. 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类型来表示成败,而是采用另外一种方式:当读取成功时,返回的是 具体和设备有关的数值;当失败时,返回的是默认数值。听起来这函数功能有点奇怪,也怀疑在什么情况下才会采用如此设计,但可惜本文主题不是讨论该函数能干 什么,或应该出现于什么地点,我们只要知道有这么一种函数即可。

我们姑且假设这函数原型如下:

  1. DWORD GetDevDW(HANDLE hDev,DWORD dwError);  
DWORD GetDevDW(HANDLE hDev,DWORD dwError);

    调用也很简单:

  1. DWORD dwVal = GetDevDW(hDev,ERROR_VALUE);  
DWORD dwVal = GetDevDW(hDev,ERROR_VALUE);


在这个例子中,如果dwVal的数值等于ERROR_VALUE,那么意味着调用GetDevDW失败;不等于ERROR_VALUE才意味着调用成功。

现在我们有两个函数,分别用来获取两个设备的信息。在接下来的例子中,我们采用#define来定义固定值:

  1. void GetDev1Info()  
  2. {  
  3.   ....  
  4.     
  5.     #define ERROR_VALUE 0  
  6.     GetDevDW(NULL,ERROR_VALUE);  
  7.       
  8.     ...  
  9. }  
  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函数做一些额外的工作:

  1. void GetDev2Info()  
  2. {  
  3.   ....  
  4.     
  5.   #ifdef ERROR_VALUE  
  6.     #undef ERROR_VALUE  
  7.   #endif  
  8.     
  9.     #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); ... }

    问题解决了,警告没有了,但代码却丑陋了。

还有另一种方式,更改固定值的名称:

  1. void GetDev1Info()  
  2. {  
  3.   ....  
  4.     
  5.     #define DEV1_ERROR_VALUE 0  
  6.     GetDevDW(NULL,DEV1_ERROR_VALUE);  
  7.       
  8.     ...  
  9. }  
  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呢?

  1. void GetDev1Info()  
  2. {  
  3.   ...  
  4.     
  5.     const DWORD ERROR_VALUE = 0;  
  6.     GetDevDW(NULL,ERROR_VALUE);  
  7.       
  8.     ....  
  9. }  
  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,在头文件中我们可能这么写:

  1. ///////////////////////////////////  
  2. //Bass.h  
  3. #define MAX_VOLUME 15  
/////////////////////////////////// //Bass.h #define MAX_VOLUME 15
  1. ///////////////////////////////////  
  2. //Amplifier.h  
  3. #define MAX_VOLUME 30  
/////////////////////////////////// //Amplifier.h #define MAX_VOLUME 30

    当两个头文件没有同时使用时,一切都很顺利,不是嘛?

但如果我需要同时控制着两个音量,那么我们就必须要同时include这两个文件,像这种调用大家应该不陌生吧:

  1. #include "Bass.h"  
  2. #include "Amplifier.h"  
#include "Bass.h" #include "Amplifier.h"

    那么问题就很显然:严重的警告或是无法通过编译。

为了解决这个问题,我们还是只能请出const。只不过,如果还是简单地声明如下:

  1. ///////////////////////////////////  
  2. //Bass.h  
  3. const DWORD MAX_VOLUME = 15;  
/////////////////////////////////// //Bass.h const DWORD MAX_VOLUME = 15;
  1. ///////////////////////////////////  
  2. //Amplifier.h  
  3. const DWORD MAX_VOLUME = 30;  
/////////////////////////////////// //Amplifier.h const DWORD MAX_VOLUME = 30;

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

  1. ///////////////////////////////////  
  2. //Bass.h  
  3. namespace Bass  
  4. {  
  5.  const DWORD MAX_VOLUME = 15;  
  6. };
  1. ///////////////////////////////////  
  2. //Amplifier.h  
  3. namespace Amplifier  
  4. {  
  5.  const DWORD MAX_VOLUME = 30;  
  6. }  
/////////////////////////////////// //Amplifier.h namespace Amplifier { const DWORD MAX_VOLUME = 30; }

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

  1. DWORD dwBass = Bass::MAX_VOLUME;  
  2. 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。

我们再回过头来看看文章最初的例子,将其封装为一个函数

  1. BOOL SwitchMode(DWORD mode)  
  2. {  
  3.   ...  
  4.     
  5.   switch(mode)  
  6.   {  
  7.     case SLEEP:  
  8.      //TO Do someting.  
  9.      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; } ... }

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

  1. const DWORD SLEEP = 0x00;  
  2. const DWORD POWER_OFF = 0x02;  
  3. const DWORD POWER_ON = 0x03;  
const DWORD SLEEP = 0x00; const DWORD POWER_OFF = 0x02; const DWORD POWER_ON = 0x03;

    调用的时候:

  1. SwitchMode(SLEEP);  
  2.   
  3. ...  
  4.   
  5. SwitchMode(POWER_OFF);  
  6.   
  7. ...  
SwitchMode(SLEEP); ... SwitchMode(POWER_OFF); ...

    很好,很漂亮,难道不是么?

但这样子无法保证使用者不是如此调用代码:

  1. SwitchMode(0x100);  
SwitchMode(0x100);

    0x100不是我们想要的数值,在SwitchMode函数也不会对该数值有相应的处理,但偏偏这符合编译器的规范,它会让这代码没有任何警告没有任何错误顺利编译通过。

也许还有人说,谁会那么傻,直接用0x100来赋值啊?这话确实没错,直接用0x100的概率确实太少了。

但我们无法否认,会有这么一种可能:有另外一个函数,其中一个固定值为如下定义:

  1. const DWORD FILE_MODE = 0x100;  
const DWORD FILE_MODE = 0x100;

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

  1. SwitchMode(FILE_MODE);  
SwitchMode(FILE_MODE);

    对于编译器来说,无论是0x100还是FILE_MODE,都没有太多意义,所以这病态代码很容易通过编译器检测;而对于人而言,因为已经使用了固定值,也下意识以为这参数是符合的。两者,无论是编译器,还是我们,都被合理地蒙骗了。

那么,我们有办法在编译的时候,如果该数值不是我们所想要的,编译器能给使用者提示警告甚至错误么?

一切皆有可能!不过,这时候我们不能使用const,而必须换用enum。

首先用enum定义固定值:

  1. enum Mode  
  2. {  
  3.     SLEEP,  
  4.     POWER_OFF,  
  5.     POWER_ON,  
  6. };  
enum Mode { SLEEP, POWER_OFF, POWER_ON, };

    函数的声明如此更换:

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

    调用也是和之前无异:

  1. SwitchMode(SLEEP);  
  2.   
  3. ...  
  4.   
  5. SwitchMode(POWER_OFF);  
  6.   
  7. ...  
SwitchMode(SLEEP); ... SwitchMode(POWER_OFF); ...

    唯一的不同就是,如果你这样调用:

  1. SwitchMode(0x100); //这时候无法编译通过  
  2. SwitchMode(FILE_MODE); //这时候无法编译通过  
SwitchMode(0x100); //这时候无法编译通过 SwitchMode(FILE_MODE); //这时候无法编译通过

    那么编译器就会毫不犹豫地发出抱怨:cannot convert parameter 1 from 'int' to 'Mode'。

很好,编译器已经作为我们的第一道防火墙,将我们所不需要的毫无关联的数值通通排除在外。难道不是很美好吗?

当然,如果你想强制让编译器通过异样的数值也不是不可能

  1. SwitchMode(static_cast<Mode>(0x100));   
SwitchMode(static_cast<Mode>(0x100));

    虽然0x100不处于Mode的范围之内,但依然还是通过了编译器的检测。对此,我们毫无办法。只是,像这种极端的异教徒的做法,有多少情况下会碰到呢?


最后的最后,我们略微总结一下:

1.只是声明单一固定值,尽可能采用const。

2.如果是一组固定值,并且互相有关联,则采用enum。

3.不涉及条件编译,只是定义固定值的情形下,尽可能不使用#define。


标题SpringBoot智能在线预约挂号系统研究AI更换标题第1章引言介绍智能在线预约挂号系统的研究背景、意义、国内外研究现状及论文创新点。1.1研究背景与意义阐述智能在线预约挂号系统对提升医疗服务效率的重要性。1.2国内外研究现状分析国内外智能在线预约挂号系统的研究与应用情况。1.3研究方法及创新点概述本文采用的技术路线、研究方法及主要创新点。第2章相关理论总结智能在线预约挂号系统相关理论,包括系统架构、开发技术等。2.1系统架构设计理论介绍系统架构设计的基本原则常用方法。2.2SpringBoot开发框架理论阐述SpringBoot框架的特点、优势及其在系统开发中的应用。2.3数据库设计与管理理论介绍数据库设计原则、数据模型及数据库管理系统。2.4网络安全与数据保护理论讨论网络安全威胁、数据保护技术及其在系统中的应用。第3章SpringBoot智能在线预约挂号系统设计详细介绍系统的设计方案,包括功能模块划分、数据库设计等。3.1系统功能模块设计划分系统功能模块,如用户管理、挂号管理、医生排班等。3.2数据库设计与实现设计数据库表结构,确定字段类型、主键及外键关系。3.3用户界面设计设计用户友好的界面,提升用户体验。3.4系统安全设计阐述系统安全策略,包括用户认证、数据加密等。第4章系统实现与测试介绍系统的实现过程,包括编码、测试及优化等。4.1系统编码实现采用SpringBoot框架进行系统编码实现。4.2系统测试方法介绍系统测试的方法、步骤及测试用例设计。4.3系统性能测试与分析对系统进行性能测试,分析测试结果并提出优化建议。4.4系统优化与改进根据测试结果对系统进行优化改进,提升系统性能。第5章研究结果呈现系统实现后的效果,包括功能实现、性能提升等。5.1系统功能实现效果展示系统各功能模块的实现效果,如挂号成功界面等。5.2系统性能提升效果对比优化前后的系统性能
在金融行业中,对信用风险的判断是核心环节之一,其结果对机构的信贷政策风险控制策略有直接影响。本文将围绕如何借助机器学习方法,尤其是Sklearn工具包,建立用于判断信用状况的预测系统。文中将涵盖逻辑回归、支持向量机等常见方法,并通过实际操作流程进行说明。 一、机器学习基本概念 机器学习属于人工智能的子领域,其基本理念是通过数据自动学习规律,而非依赖人工设定规则。在信贷分析中,该技术可用于挖掘历史数据中的潜在规律,进而对未来的信用表现进行预测。 二、Sklearn工具包概述 Sklearn(Scikit-learn)是Python语言中广泛使用的机器学习模块,提供多种数据处理建模功能。它简化了数据清洗、特征提取、模型构建、验证与优化等流程,是数据科学项目中的常用工具。 三、逻辑回归模型 逻辑回归是一种常用于分类任务的线性模型,特别适用于二类问题。在信用评估中,该模型可用于判断借款人是否可能违约。其通过逻辑函数将输出映射为0到1之间的概率值,从而表示违约的可能性。 四、支持向量机模型 支持向量机是一种用于监督学习的算法,适用于数据维度高、样本量小的情况。在信用分析中,该方法能够通过寻找最佳分割面,区分违约与非违约客户。通过选用不同核函数,可应对复杂的非线性关系,提升预测精度。 五、数据预处理步骤 在建模前,需对原始数据进行清理与转换,包括处理缺失值、识别异常点、标准化数值、筛选有效特征等。对于信用评分,常见的输入变量包括收入水平、负债比例、信用历史记录、职业稳定性等。预处理有助于减少噪声干扰,增强模型的适应性。 六、模型构建与验证 借助Sklearn,可以将数据集划分为训练集测试集,并通过交叉验证调整参数以提升模型性能。常用评估指标包括准确率、召回率、F1值以及AUC-ROC曲线。在处理不平衡数据时,更应关注模型的召回率与特异性。 七、集成学习方法 为提升模型预测能力,可采用集成策略,如结合多个模型的预测结果。这有助于降低单一模型的偏差与方差,增强整体预测的稳定性与准确性。 综上,基于机器学习的信用评估系统可通过Sklearn中的多种算法,结合合理的数据处理与模型优化,实现对借款人信用状况的精准判断。在实际应用中,需持续调整模型以适应市场变化,保障预测结果的长期有效性。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值