1、枚举类型所占字节数的讨论enum型用于定义常量集合，相比#define有一些优势，但enum也有一个隐含问题：enum变量占用的空间与编译器相关。首先，我们先来看一下enum和#define的比较 1、#define宏常量是在预编译阶段进行简单的替换，枚举常量是在编译器确定其值。 2、 一般在编译器里面，可以调试枚举常量，但是不可以调试宏常量 3、枚举可以一次定义大量的相关的常量，而#define宏一次只能定义一个。 4、枚举常量属于常量，宏没有这个说法。 5、枚举常量具有类型，使用时会检查类型匹配，但宏没有类型，枚举变量具有与普通变量相同的诸如作用域、值等性质，但宏没有如：enum是一种数据
2、类型，使用时会检查类型匹配；enum增加了范围约束，避免变量赋值和使用时超出定义范围。多数编译器默认enum型长度等于int型，很多人也把enum型变量等同于int，但C标准在这里留下了尾巴：“枚举型尺寸是能够容纳最大枚举子值的整数尺寸”，“枚举类型中枚举子的值必须要能用一个int型表述”。也就是说，枚举型的尺寸不能超过int型，但不必等于int型，只要能容纳最大枚举就行，下例： enum EType1 e1 = CHAR_MAX ; enum EType2 e2 = SHORT_MAX ; 这两个枚举类型最小可用char、short的内存空间表示，即有可能： sizeof( EType1 )
3、 = sizeof( char ); sizeof( EType2 ) = sizeof( short );一些编译器为节约内存可以设置这种“量体裁衣”的策略。如ADS就有图示选项(enumContaineralways int)，选定后enum变量长度为int，否则就等于能容纳最大枚举的最短长度。gcc也有类似选项-fshort-enums，默认不设定，一旦设置就选用节省内存的enum长度。enum长度不确定会带来可移植性问题，如果第三方库API接口使用enum类型，编译和调用库时一旦有关enum长度的编译器设置不一致，API接口层对数值的解析就不匹配。比如上层应用编译时没有用-fshort-enums，默认用4字节空间来存储使用enum变量，而编译库时设置了fshort-enums，则库内部此enum size可能为1。当把enum变量地址传进API时，内部只修改变量最低字节，高3字节值无变化（内容随机），API返回时，上层使用的4字节enum变量值就可能随机。因此内部代码使用enum类型优于#define，但对外API接口尽量避免用enum型。
