轉載僅用於學習： 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