至從C語言開始enum類型就被作為用戶自定義分類有限集合常量的方法被引入到了語言當中，而且一度成為C++中定義編譯期常量的唯一方法（后來在類中引入了靜態整型常量）。
根據上面對enum類型的描述，有以下幾個問題：
1.到底enum所定義出來的類型是一個什么樣的類型呢？
2.作為一個用戶自定義的類型其所占用的內存空間是多少呢？
3.使用enum類型是否真的能夠起到有限集合常量的邊界約束呢？
4.大家可能都知道enum類型和int類型具有隱示（自動）轉換的規則，那么是否真的在任何地方都可以使用enum類型的變量來代替int類型的變量呢？
1. 到底enum所定義出來的類型是一個什么樣的類型呢？
在C++中大家都知道僅僅有兩種大的類型分類：POD類型（注（1））和類類型。
enum所定義的類型其實屬于POD類型，也就是說它會參與到POD類型的隱示轉換規則當中去，所以才會出現enum類型與int類型之間的隱示轉換現象。
那么也就是說enum所定義的類型不具備名字空間限定能力（因為不屬于類類型），其所定義的常量子具備和enum類型所在名字空間相同的可見性，由于自身沒有名字限定能力，所以會出現名字沖突現象。
如：
struct CEType
{
enum EType1 { e1, e2 };
enum EType2 { e1, e2 };
};
上面的例子會出現e1、e2名字沖突編譯時錯誤，原因就在于枚舉子（e1、e2）是CEType名字空間中的名字，同樣在引用該CEType中的枚舉子時必須采用CEType::e1這樣的方式進行，而不是CEType::EType1::e1來進行引用。
注（1）POD類型：
你可以將 POD 類型看作是一種來自外太空的用綠色保護層包裝的數據類型，POD 意為“Plain Old Data”（譯者：如果一定要譯成中文，那就叫“徹頭徹尾的老數據”怎么樣！）這就是 POD 類型的含義。
其確切定義相當粗糙（參見 C++ ISO 標準），其基本意思是 POD 類型包含與 C 兼容的原始數據。
例如，結構和整型是 POD 類型，但帶有構造函數或虛擬函數的類則不是。
POD 類型沒有虛擬函數，基類，用戶定義的構造函數，拷貝構造，賦值操作符或析構函數。
為了將 POD 類型概念化，你可以通過拷貝其比特來拷貝它們。此外， POD 類型可以是非初始化的。
2. 作為一個用戶自定義的類型其所占用的內存空間是多少呢？
該問題就是sizeof( EType1 )等于多少的問題，是不是每一個用戶自定義的枚舉類型都具有相同的尺寸呢？
在大多數的32位編譯器下（如：VC++、gcc等）一個枚舉類型的尺寸其實就是一個sizeof( int )的大小，難道枚舉類型的尺寸真的就應該是int類型的尺寸嗎？
其實不是這樣的，在C++標準文檔（ISO14882）中并沒有這樣來定義，
標準中是這樣說明的：“枚舉類型的尺寸是以能夠容納最大枚舉子的值的整數的尺寸”，
同時標準中也說名了：“枚舉類型中的枚舉子的值必須要能夠用一個int類型表述”，
也就是說，枚舉類型的尺寸不能夠超過int類型的尺寸，但是是不是必須和int類型具有相同的尺寸呢？
上面的標準已經說得很清楚了，只要能夠容納最大的枚舉子的值的整數就可以了，那么就是說可以是char、short和int。
例如：
enum EType1 { e1 = CHAR_MAX };
enum EType2 { e2 = SHRT_MAX };
enum EType3 { e3 = INT_MAX };
上面的三個枚舉類型分別可以用char、short、int的內存空間進行表示，也就是：
sizeof( EType1 ) == sizeof( char );
sizeof( EType2 ) == sizeof( short );
sizeof( EType3 ) == sizeof( int );
那為什么在32位的編譯器下都會將上面三個枚舉類型的尺寸編譯成int類型的尺寸呢？
主要是從32位數據內存對其方面的要求進行考慮的，在某些計算機硬件環境下具有對齊的強制性要求（如：sun SPARC），
有些則是因為采用一個完整的32位字長CPU處理效率非常高的原因（如：IA32）。
所以不可以簡單的假設枚舉類型的尺寸就是int類型的尺寸，說不定會遇到一個編譯器為了節約內存而采用上面的處理策略。
3. 使用enum類型是否真的能夠起到有限集合常量的邊界約束呢？
首先看一下下面這個例子：
enum EType { e1 = 0, e2 };
void func1( EType e )
{
if ( e == e1 )
{
// do something
}
// do something because e != e1 must e == e2
}
void func2( EType e )
{
if ( e == e1 )
{
// do something
}
else if ( e == e2 )
{
// do something
}
}
func1( static_cast<EType>( 2 ) );
func2( static_cast<EType>( -1 ) );
上面的代碼應該很清楚的說明了這樣一種異常的情況了，在使用一個操出范圍的整型值調用func1函數時會導致函數采取不該采取的行為，而第二個函數可能會好一些他僅僅是忽略了超出范圍的值。
這就說明枚舉所定義的類型并不是一個真正強類型的有限常量集合，這樣一種條件下和將上述的兩個函數參數聲明成為整數類型沒有任何差異。所以以后要注意標準定義中枚舉類型的陷阱。
（其實只有類類型才是真正的強類型）
4. 是否真的在任何地方都可以使用enum類型的變量來代替int類型的變量呢？
通過上面的討論，其實枚舉類型的變量和整型變量具有了太多的一致性和可互換性,那么是不是在每一個可以使用int類型的地方都可以很好的用枚舉類型來替代呢？
其實也不是這樣的，畢竟枚舉類型是一個在編譯時可區分的類型，
同時第2點的分析枚舉類型不一定和int類型具有相同的尺寸，這兩個差異就決定了在某些場合是不可以使用枚舉類型來代替int類型的。
如：
第一種情況：
enum EType { e1 = 0, e2, e3 };
EType val;
std::cin >> val;
第二種情況：
enum EType { e1 = 0, e2, e3 };
EType val;
std::scanf( "%d", &val );
上面的兩種情況看是基本上屬于同一種類型的問題，其實不然。第一種情況會導致編譯時錯誤，
會因為std::cin沒有定義對應的枚舉類型的重載>>運算符而出錯，這就說明枚舉類型是一種獨立和鑒別的類型；
而第二種情況不會有任何編譯時問題，但是可能會導致scanf函數棧被破壞而使得程序運行非法，為什么會這樣呢？
上面已經分析過了枚舉類型變量的尺寸不一定和int類型相同，這樣一來我們采用%d就是說將枚舉類型變量val當作4字節的int變量來看待并進行參數壓棧，
而在某些編譯器下sizeof( val )等于1字節，這樣scanf函數就會將val變量地址中的后續的三字節地址也壓入棧中，
并對其進行賦值，也許val變量后續的三個字節的地址沒有特殊含義可以被改寫（比如是字節對齊的空地址空間），
可能會認為他不會出現錯誤，其實不然，在scanf函數調用結束后會進行棧清理，
這樣一來會導致scanf函數清理了過多的地址空間，從而破壞了外圍函數的棧指針的指向，從而必然會導致程序運行時錯誤。
由上面的說明枚舉類型有那么多的缺點，那我們怎樣才能夠有一個類型安全的枚舉類型呢？實際上，在最新的 C++0x 標準草案中有關于枚舉作用域問題的提案，但最終的解決方案會是怎樣的就無法未卜先知了，畢竟對于象 C++ 這樣使用廣泛的語言來說，任何特性的增刪和修改都必須十分小心謹慎。
當然，我們可以使用一些迂回的方法來解決這個問題（C++ 總是能給我們很多驚喜和意外）。
例如，我們可以把枚舉值放在一個結構里，并使用運算符重載來逼近枚舉的特性：
struct FileAccess {
enum __Enum {
Read = 0x1,
Write = 0x2
};
__Enum _value; // 枚舉值
FileAccess(int value = 0) : _value((__Enum)value) {}
FileAccess& operator=(int value) {
this->_value = (__Enum)value;
return *this;
}
operator int() const {
return this->_value;
}
};
我們現在可以按照希望的方式使用這個枚舉類型：
FileAccess access = FileAccess::Read;
并且，因為我們提供了到 int 類型的轉換運算符，因此在需要 int 的地方都可以使用它，例如 switch 語句：
switch (access) {
case FileAccess::Read:
break;
case FileAccess::Write:
break;
}
當然我們不愿意每次都手工編寫這樣的結構。通過使用宏，我們可以很容易做到這一點：
#define DECLARE_ENUM(E) \
struct E \
{ \
public: \
E(int value = 0) : _value((__Enum)value) { \
} \
E& operator=(int value) { \
this->_value = (__Enum)value; \
return *this; \
} \
operator int() const { \
return this->_value; \
} \
\
enum __Enum {
#define END_ENUM() \
}; \
\
private: \
__Enum _value; \
};
我們現在可以按如下的方式定義前面的枚舉，并且不比直接寫 enum 復雜多少。
DECLARE_ENUM(FileAccess)
Read = 0x1,
Write = 0x2,
END_ENUM()
DECLARE_ENUM(FileShare)
Read = 0x1,
Write = 0x2,
END_ENUM()