• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 28, comments - 179, trackbacks - 0, articles - 1
              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

            enum類型的本質(zhì)

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

                由上面的說明枚舉類型有那么多的缺點,那我們怎樣才能夠有一個類型安全的枚舉類型
            呢?其實可以采用類類型來模擬枚舉類型的有限常量集合的概念,同時得到類型安全的好處,
            具體參見后續(xù)的文章。

            Feedback

            # re: enum類型的本質(zhì)  回復(fù)  更多評論   

            2007-06-05 17:42 by walkspeed
            邏輯清晰,表達(dá)清楚,容易閱讀。
            作者的勤于思考和樂于實踐和總結(jié)的精神值得大家學(xué)習(xí)。

            多些原創(chuàng)好。

            # re: enum類型的本質(zhì)  回復(fù)  更多評論   

            2007-06-05 23:53 by silentfish
            很清晰,很全面:感謝1

            # re: enum類型的本質(zhì)  回復(fù)  更多評論   

            2008-06-25 11:13 by d.k
            贊一個。。。

            # re: enum類型的本質(zhì)  回復(fù)  更多評論   

            2008-08-08 10:54 by calmspeaker
            感謝您的文章,受益匪淺
            我沒有找到您的關(guān)于“POD類型和類類型”的文章,十分想拜讀一下。

            # re: enum類型的本質(zhì)  回復(fù)  更多評論   

            2008-10-10 11:05 by laoda
            不錯,支持原創(chuàng),支持精品

            # re: enum類型的本質(zhì)  回復(fù)  更多評論   

            2008-10-10 13:59 by
            相當(dāng)精彩,支持作者的思考,感謝作者的分享

            # re: enum類型的本質(zhì)  回復(fù)  更多評論   

            2009-08-07 18:43 by
            文章不錯,吊人胃口不是好習(xí)慣.

            # re: enum類型的本質(zhì)  回復(fù)  更多評論   

            2009-08-07 18:44 by
            有沒有見過此種BT的用法?我反正是不明白.還請賜教.
            class CBase
            {
            public:
            enum MyBaseEnum;
            };
            class CDevBase: public CBase
            {
            public:
            extern enum CBase::MyBaseEnum
            {
            MBE_1 = 0,
            };
            };

            # re: enum類型的本質(zhì)  回復(fù)  更多評論   

            2010-05-15 16:16 by parser
            正好遇到一個相關(guān)的問題就google到樓主了,講得很清楚,贊一個!飄走

            # re: enum類型的本質(zhì)  回復(fù)  更多評論   

            2015-01-07 21:23 by 尋水的駱駝
            作者思考的很深入很仔細(xì)
            91久久精一区二区三区大全| 久久精品国产99国产精品| 日韩欧美亚洲综合久久影院Ds| 欧美性猛交xxxx免费看久久久| 亚洲Av无码国产情品久久| 成人午夜精品无码区久久 | 久久97精品久久久久久久不卡| 亚洲精品国产成人99久久| 久久亚洲熟女cc98cm| 久久本道伊人久久| 伊人情人综合成人久久网小说| avtt天堂网久久精品| 日韩欧美亚洲国产精品字幕久久久 | 久久99九九国产免费看小说| 久久99精品国产一区二区三区| 色偷偷88欧美精品久久久| 久久国产一区二区| 亚洲人成精品久久久久| 久久免费99精品国产自在现线| 国内精品九九久久久精品| 97精品依人久久久大香线蕉97 | 久久久久亚洲AV无码专区体验| 国产精品99久久久久久猫咪| 无码人妻久久一区二区三区免费丨 | 成人资源影音先锋久久资源网| 久久久久久久波多野结衣高潮 | 久久综合九色综合久99| 精品久久久中文字幕人妻 | 国产成人久久精品区一区二区| 久久久精品久久久久影院| 色综合久久中文综合网| 久久99国产精品99久久| 欧美久久久久久午夜精品| 久久精品国内一区二区三区| 久久精品无码专区免费东京热| 欧美精品乱码99久久蜜桃| 午夜精品久久久久久久无码| 精品一久久香蕉国产线看播放| 狠狠色伊人久久精品综合网| 久久亚洲AV无码西西人体| 无码人妻久久一区二区三区蜜桃|