青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

posts - 28, comments - 179, trackbacks - 0, articles - 1
  C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

enum類型的本質

Posted on 2007-06-05 16:20 chemz 閱讀(20883) 評論(10)  編輯 收藏 引用 所屬分類: C++
                                 enum類型的本質
    至從C語言開始enum類型就被作為用戶自定義分類有限集合常量的方法被引入到了語言
當中,而且一度成為C++中定義編譯期常量的唯一方法(后來在類中引入了靜態整型常量)。
    根據上面對enum類型的描述,到底enum所定義出來的類型是一個什么樣的類型呢?作為
一個用戶自定義的類型其所占用的內存空間是多少呢?使用enum類型是否真的能夠起到有限
集合常量的邊界約束呢?大家可能都知道enum類型和int類型具有隱示(自動)轉換的規則,
那么是否真的在任何地方都可以使用enum類型的變量來代替int類型的變量呢?下面會逐一
回答這些問題。
    1. 到底enum所定義出來的類型是一個什么樣的類型呢?
       在C++中大家都知道僅僅有兩種大的類型分類:POD類型和類類型(不清楚的可以參
       見我的其他文章)。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來進行引用。
    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函數
       清理了過多的地址空間,從而破壞了外圍函數的棧指針的指向,從而必然會導致程
       序運行時錯誤。

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

Feedback

# re: enum類型的本質  回復  更多評論   

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

多些原創好。

# re: enum類型的本質  回復  更多評論   

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

# re: enum類型的本質  回復  更多評論   

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

# re: enum類型的本質  回復  更多評論   

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

# re: enum類型的本質  回復  更多評論   

2008-10-10 11:05 by laoda
不錯,支持原創,支持精品

# re: enum類型的本質  回復  更多評論   

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

# re: enum類型的本質  回復  更多評論   

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

# re: enum類型的本質  回復  更多評論   

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類型的本質  回復  更多評論   

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

# re: enum類型的本質  回復  更多評論   

2015-01-07 21:23 by 尋水的駱駝
作者思考的很深入很仔細
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            精品av久久久久电影| 一二三区精品福利视频| 亚洲欧洲综合另类| 国产一区二区高清| 亚洲一区二三| 亚洲综合日韩在线| 欧美日韩成人一区二区| 欧美国产日韩一二三区| 国模叶桐国产精品一区| 亚洲一区精品电影| 亚洲一区二区三区在线视频| 欧美丰满高潮xxxx喷水动漫| 免费黄网站欧美| 国产一区激情| 久久se精品一区二区| 欧美在线视频二区| 国产麻豆精品视频| 亚洲精品欧美日韩专区| 99精品热6080yy久久 | 蜜臀va亚洲va欧美va天堂| 欧美在线视频在线播放完整版免费观看| 欧美激情亚洲| 亚洲伦理在线| 亚洲性夜色噜噜噜7777| 国产精品av免费在线观看| 99国产精品国产精品久久| 欧美激情一区二区三区高清视频 | 狠狠色狠狠色综合| 午夜精品福利一区二区三区av| 亚洲欧美激情精品一区二区| 欧美午夜无遮挡| 国产日韩欧美电影在线观看| 极品av少妇一区二区| 欧美一区二区三区在线观看视频 | 亚洲美女诱惑| 一区二区三区日韩欧美| 欧美揉bbbbb揉bbbbb| 99re热精品| 欧美一级大片在线观看| 国产午夜一区二区三区| 久久国产婷婷国产香蕉| 欧美激情片在线观看| 9人人澡人人爽人人精品| 欧美视频一区二区三区在线观看| 亚洲视频一区二区免费在线观看| 亚洲伊人伊色伊影伊综合网| 国产欧美日韩在线视频| 可以看av的网站久久看| 99国产精品国产精品久久| 欧美一区二区三区在线| 国产在线国偷精品产拍免费yy| 亚洲一区二区3| 久久电影一区| 亚洲国产一成人久久精品| 欧美激情一区二区三区四区| 99re亚洲国产精品| 久久久久久国产精品一区| 最新热久久免费视频| 国产精品扒开腿做爽爽爽软件| 香蕉av777xxx色综合一区| 欧美国产先锋| 性刺激综合网| 99re热这里只有精品视频| 国产日韩欧美高清免费| 欧美成人一区二免费视频软件| 中国av一区| 久久综合久久综合久久| 亚洲神马久久| 亚洲国产高清视频| 国产九色精品成人porny| 免费观看成人鲁鲁鲁鲁鲁视频| 亚洲午夜在线观看| 亚洲激情国产精品| 欧美一级午夜免费电影| 一区二区三区在线免费视频| 欧美日韩一区二区免费在线观看| 欧美一区二区三区在线免费观看| 亚洲精品久久久久久久久久久久久| 久久av资源网| 亚洲视频第一页| 亚洲国产精品va在线看黑人| 国产美女精品免费电影| 欧美日韩亚洲免费| 欧美高清在线观看| 久久久国产视频91| 欧美一区成人| 亚洲女女女同性video| 99这里只有久久精品视频| 欧美成人免费在线视频| 久久久久久亚洲精品杨幂换脸| 亚洲欧美激情一区| 宅男在线国产精品| 亚洲精品护士| 91久久精品一区二区别| 亚洲高清影视| 国产精品福利影院| 久久久久久网站| 亚洲欧美在线一区| 日韩视频一区二区在线观看 | 蜜臀va亚洲va欧美va天堂| 午夜精品偷拍| 亚洲综合精品| 亚洲综合国产精品| 亚洲中字在线| 亚洲男人影院| 先锋影音一区二区三区| 亚洲欧美区自拍先锋| 亚洲女性裸体视频| 欧美一区二视频| 欧美在线日韩| 久久伊人一区二区| 久久福利视频导航| 久热精品视频在线免费观看| 久久在线免费观看| 欧美国产视频在线观看| 欧美日韩精品一区二区三区四区| 国产亚洲永久域名| 亚洲无亚洲人成网站77777| 日韩视频免费在线| 亚洲精品免费观看| 亚洲美女黄色| 亚洲一区二区高清| 午夜精品福利一区二区蜜股av| 亚洲在线免费观看| 亚洲一级免费视频| 香蕉久久久久久久av网站| 久久疯狂做爰流白浆xx| 老司机aⅴ在线精品导航| 欧美激情精品久久久久久| 欧美视频精品一区| 国产精品欧美日韩一区二区| 好吊日精品视频| 亚洲精品美女久久久久| 亚洲制服少妇| 久久综合久久综合久久| 亚洲国产欧美国产综合一区 | 久久九九热免费视频| 久久婷婷人人澡人人喊人人爽| 欧美韩国日本综合| 日韩一级视频免费观看在线| 欧美激情中文字幕一区二区| 99精品福利视频| 欧美影院成人| 欧美久久久久久| 国产热re99久久6国产精品| 亚洲日韩视频| 欧美一级片在线播放| 亚洲福利一区| 午夜精品一区二区三区在线视| 玖玖视频精品| 国产日韩精品一区| 一本久久青青| 美日韩在线观看| 亚洲一区二区久久| 欧美成人精品h版在线观看| 国产欧美日韩| 99精品久久免费看蜜臀剧情介绍| 久久超碰97中文字幕| 亚洲精品色图| 老鸭窝91久久精品色噜噜导演| 国产精品日韩一区二区三区| 亚洲理论电影网| 蜜桃av一区二区三区| 亚洲一区二区伦理| 欧美日韩国产三区| 亚洲黄一区二区| 美脚丝袜一区二区三区在线观看| 亚洲一区二区三区涩| 欧美区在线观看| 亚洲人人精品| 欧美成人日韩| 久久久最新网址| 国产一区二区三区高清播放| 亚洲欧美日韩精品久久奇米色影视| 亚洲国产精品悠悠久久琪琪| 久久久久欧美精品| 国产一区二区精品丝袜| 欧美在线视频网站| 亚洲一区二区视频| 国产精品久久久久9999| 亚洲夜间福利| 日韩一二在线观看| 欧美日韩一区二区国产| 宅男噜噜噜66一区二区| 亚洲日韩欧美一区二区在线| 欧美69视频| 亚洲精品自在久久| 亚洲第一综合天堂另类专| 久久字幕精品一区| 亚洲黄页视频免费观看| 欧美黄色aaaa| 欧美精品播放| 夜夜嗨一区二区三区| 日韩视频在线一区二区| 欧美午夜激情视频| 美女国内精品自产拍在线播放| 免费不卡欧美自拍视频| 久久久久亚洲综合| 亚洲电影中文字幕| 欧美成人免费视频|