chemz

                                 enum類型的本質(zhì)
    至從C語(yǔ)言開(kāi)始enum類型就被作為用戶自定義分類有限集合常量的方法被引入到了語(yǔ)言
當(dāng)中，而且一度成為C++中定義編譯期常量的唯一方法（后來(lái)在類中引入了靜態(tài)整型常量）。
    根據(jù)上面對(duì)enum類型的描述，到底enum所定義出來(lái)的類型是一個(gè)什么樣的類型呢？作為
一個(gè)用戶自定義的類型其所占用的內(nèi)存空間是多少呢？使用enum類型是否真的能夠起到有限
集合常量的邊界約束呢？大家可能都知道enum類型和int類型具有隱示（自動(dòng)）轉(zhuǎn)換的規(guī)則，
那么是否真的在任何地方都可以使用enum類型的變量來(lái)代替int類型的變量呢？下面會(huì)逐一
回答這些問(wèn)題。
    1. 到底enum所定義出來(lái)的類型是一個(gè)什么樣的類型呢？
       在C++中大家都知道僅僅有兩種大的類型分類：POD類型和類類型（不清楚的可以參
       見(jiàn)我的其他文章）。enum所定義的類型其實(shí)屬于POD類型，也就是說(shuō)它會(huì)參與到POD
       類型的隱示轉(zhuǎn)換規(guī)則當(dāng)中去，所以才會(huì)出現(xiàn)enum類型與int類型之間的隱示轉(zhuǎn)換現(xiàn)象。
       那么也就是說(shuō)enum所定義的類型不具備名字空間限定能力（因?yàn)椴粚儆陬愵愋停?br>       其所定義的常量子具備和enum類型所在名字空間相同的可見(jiàn)性，由于自身沒(méi)有名字
       限定能力，所以會(huì)出現(xiàn)名字沖突現(xiàn)象。如：
           struct CEType
           {
               enum EType1 { e1, e2 };
               enum EType2 { e1, e2 };
           };
       上面的例子會(huì)出現(xiàn)e1、e2名字沖突編譯時(shí)錯(cuò)誤，原因就在于枚舉子（e1、e2）是
       CEType名字空間中的名字，同樣在引用該CEType中的枚舉子時(shí)必須采用CEType::e1
       這樣的方式進(jìn)行，而不是CEType::EType1::e1來(lái)進(jìn)行引用。
    2. 作為一個(gè)用戶自定義的類型其所占用的內(nèi)存空間是多少呢？
       該問(wèn)題就是sizeof( EType1 )等于多少的問(wèn)題，是不是每一個(gè)用戶自定義的枚舉類
       型都具有相同的尺寸呢？在大多數(shù)的32位編譯器下（如：VC++、gcc等）一個(gè)枚舉類
       型的尺寸其實(shí)就是一個(gè)sizeof( int )的大小，難道枚舉類型的尺寸真的就應(yīng)該是int
       類型的尺寸嗎？其實(shí)不是這樣的，在C++標(biāo)準(zhǔn)文檔（ISO14882）中并沒(méi)有這樣來(lái)定義，
       標(biāo)準(zhǔn)中是這樣說(shuō)明的：“枚舉類型的尺寸是以能夠容納最大枚舉子的值的整數(shù)的尺寸”，
       同時(shí)標(biāo)準(zhǔn)中也說(shuō)名了：“枚舉類型中的枚舉子的值必須要能夠用一個(gè)int類型表述”，
       也就是說(shuō)，枚舉類型的尺寸不能夠超過(guò)int類型的尺寸，但是是不是必須和int類型
       具有相同的尺寸呢？上面的標(biāo)準(zhǔn)已經(jīng)說(shuō)得很清楚了，只要能夠容納最大的枚舉子的
       值的整數(shù)就可以了，那么就是說(shuō)可以是char、short和int。例如：
           enum EType1 { e1 = CHAR_MAX };
           enum EType2 { e2 = SHRT_MAX };
           enum EType3 { e3 = INT_MAX  };
       上面的三個(gè)枚舉類型分別可以用char、short、int的內(nèi)存空間進(jìn)行表示，也就是：
           sizeof( EType1 ) == sizeof( char  );
           sizeof( EType2 ) == sizeof( short );
           sizeof( EType3 ) == sizeof( int   );
       那為什么在32位的編譯器下都會(huì)將上面三個(gè)枚舉類型的尺寸編譯成int類型的尺寸呢？
       主要是從32位數(shù)據(jù)內(nèi)存對(duì)其方面的要求進(jìn)行考慮的，在某些計(jì)算機(jī)硬件環(huán)境下具有對(duì)
       齊的強(qiáng)制性要求（如：sun SPARC），有些則是因?yàn)椴捎靡粋€(gè)完整的32位字長(zhǎng)CPU處理
       效率非常高的原因（如：IA32）。所以不可以簡(jiǎn)單的假設(shè)枚舉類型的尺寸就是int類
       型的尺寸，說(shuō)不定會(huì)遇到一個(gè)編譯器為了節(jié)約內(nèi)存而采用上面的處理策略。
    3. 使用enum類型是否真的能夠起到有限集合常量的邊界約束呢？
       首先看一下下面這個(gè)例子：
           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 ) );
       上面的代碼應(yīng)該很清楚的說(shuō)明了這樣一種異常的情況了，在使用一個(gè)操出范圍的整
       型值調(diào)用func1函數(shù)時(shí)會(huì)導(dǎo)致函數(shù)采取不該采取的行為，而第二個(gè)函數(shù)可能會(huì)好一些
       他僅僅是忽略了超出范圍的值。這就說(shuō)明枚舉所定義的類型并不是一個(gè)真正強(qiáng)類型
       的有限常量集合，這樣一種條件下和將上述的兩個(gè)函數(shù)參數(shù)聲明成為整數(shù)類型沒(méi)有
       任何差異。所以以后要注意標(biāo)準(zhǔn)定義中枚舉類型的陷阱。（其實(shí)只有類類型才是真
       正的強(qiáng)類型）
      
    4. 是否真的在任何地方都可以使用enum類型的變量來(lái)代替int類型的變量呢？
       通過(guò)上面的討論，其實(shí)枚舉類型的變量和整型變量具有了太多的一致性和可互換性，
       那么是不是在每一個(gè)可以使用int類型的地方都可以很好的用枚舉類型來(lái)替代呢？
       其實(shí)也不是這樣的，畢竟枚舉類型是一個(gè)在編譯時(shí)可區(qū)分的類型，同時(shí)第2點(diǎn)的分析
       枚舉類型不一定和int類型具有相同的尺寸，這兩個(gè)差異就決定了在某些場(chǎng)合是不可
       以使用枚舉類型來(lái)代替int類型的。如：
           第一種情況：
               enum EType { e1 = 0, e2, e3 };
               EType val;
               std::cin >> val;
           第二種情況：
               enum EType { e1 = 0, e2, e3 };
               EType val;
               std::scanf( "%d", &val );
       上面的兩種情況看是基本上屬于同一種類型的問(wèn)題，其實(shí)不然。第一種情況會(huì)導(dǎo)致
       編譯時(shí)錯(cuò)誤，會(huì)因?yàn)閟td::cin沒(méi)有定義對(duì)應(yīng)的枚舉類型的重載>>運(yùn)算符而出錯(cuò)，這
       就說(shuō)明枚舉類型是一種獨(dú)立和鑒別的類型；而第二種情況不會(huì)有任何編譯時(shí)問(wèn)題，
       但是可能會(huì)導(dǎo)致scanf函數(shù)棧被破壞而使得程序運(yùn)行非法，為什么會(huì)這樣呢？上面
       已經(jīng)分析過(guò)了枚舉類型變量的尺寸不一定和int類型相同，這樣一來(lái)我們采用%d就
       是說(shuō)將枚舉類型變量val當(dāng)作4字節(jié)的int變量來(lái)看待并進(jìn)行參數(shù)壓棧，而在某些編
       譯器下sizeof( val )等于1字節(jié)，這樣scanf函數(shù)就會(huì)將val變量地址中的后續(xù)的三
       字節(jié)地址也壓入棧中，并對(duì)其進(jìn)行賦值，也許val變量后續(xù)的三個(gè)字節(jié)的地址沒(méi)有
       特殊含義可以被改寫（比如是字節(jié)對(duì)齊的空地址空間），可能會(huì)認(rèn)為他不會(huì)出現(xiàn)錯(cuò)
       誤，其實(shí)不然，在scanf函數(shù)調(diào)用結(jié)束后會(huì)進(jìn)行棧清理，這樣一來(lái)會(huì)導(dǎo)致scanf函數(shù)
       清理了過(guò)多的地址空間，從而破壞了外圍函數(shù)的棧指針的指向，從而必然會(huì)導(dǎo)致程
       序運(yùn)行時(shí)錯(cuò)誤。

    由上面的說(shuō)明枚舉類型有那么多的缺點(diǎn)，那我們?cè)鯓硬拍軌蛴幸粋€(gè)類型安全的枚舉類型
呢？其實(shí)可以采用類類型來(lái)模擬枚舉類型的有限常量集合的概念，同時(shí)得到類型安全的好處，
具體參見(jiàn)后續(xù)的文章。