转载仅用于学习： https://blog.csdn.net/ipmux/article/details/17334099
enum型用于定义常量集合，相比#define有一些优势，如：enum是一种数据类型，使用时会检查类型匹配；enum增加了范围约束，避免变量赋值和使用时超出定义范围。但enum也有一个隐含问题：enum变量占用的空间与编译器相关。
多数编译器默认enum型长度等于int型，很多人也把enum型变量等同于int，但C标准在这里留下了尾巴：“枚举型尺寸是能够容纳最大枚举子值的整数尺寸”，“枚举类型中枚举子的值必须要能用一个int型表述”。也就是说，枚举型的尺寸不能超过int型，但不必等于int型，只要能容纳最大枚举子就行，下例：
enum EType1 { e1 = CHAR_MAX };
enum EType2 { e2 = SHORT_MAX };
这两个枚举类型最小可用char、short的内存空间表示，即有可能：
sizeof( EType1 ) == sizeof( char );
sizeof( EType2 ) == sizeof( short );
一些编译器为节约内存可以设置这种“量体裁衣”的策略。如ADS就有图示选项(enum container always 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变量值就可能随机。（潜规则篇之API接口）
因此内部代码使用enum类型优于define，但对外API接口尽量避免用enum型。
————————————————
版权声明：本文为CSDN博主「ipmux」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ipmux/article/details/17334099