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

C++ 枚舉類型的思考

至從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()

posted on 2009-03-23 18:16 Randy 閱讀(6398) 評論(7)  編輯 收藏 引用

評論

# re: C++ 枚舉類型的思考 2009-09-24 15:14 gong.max

感謝,學習了  回復  更多評論   

# re: C++ 枚舉類型的思考 2010-05-12 23:04 water

那個operator int()根本就是蛇足,完全沒有用。
這段代碼:
switch (access) {
case FileAccess::Read:
break;
case FileAccess::Write:
break;
}
之所以正確,和那個operator int()完全沒有關系。從語法上分析,FileAccess::Read并不是FileAccess類型,而是FileAccess::__Enum類型的,在這里,因為enum是一個完全可以被int容納的類型,就如你所說“枚舉類型中的枚舉子的值必須要能夠用一個int類型表述”,所以自動轉換了。
迄今為止,包括msvc10,g++4.4,intel C++11在內的編譯器,把enum當成int用時,都不需要顯式的轉換。  回復  更多評論   

# re: C++ 枚舉類型的思考[未登錄] 2011-10-15 22:17 lin

在scanf函數調用結束后會進行棧清理,
這樣一來會導致scanf函數清理了過多的地址空間

能不能詳細的介紹下?不是很明白..thanks  回復  更多評論   

# re: C++ 枚舉類型的思考[未登錄] 2011-10-16 20:10 lin

按照上面的說法,傳遞進來四個字節(int占用4B)地址空間,scanf調用結束清棧的時候,不是也清除這四個字節的地址空間嗎?怎么會多清除呢?呃,解釋下好嗎,謝謝  回復  更多評論   

# re: C++ 枚舉類型的思考[未登錄] 2012-08-07 19:01 春秋十二月

不錯,但從整型到枚舉的轉換,需注意是否越界  回復  更多評論   

# re: C++ 枚舉類型的思考[未登錄] 2012-10-22 03:43 K

@water
operator int()還是需要的,在 switch (access) 中,access 是 FileAccess 類型,而 FileAccess 沒有轉換到 FileAccess::__Enum 或 int 的定義,所以如果沒有operator int(),編譯是通不過的。  回復  更多評論   

# re: C++ 枚舉類型的思考[未登錄] 2014-04-25 22:28 kk

operator int()還是需要的
支持
這個很需要的
現在C++11 出來了,域的問題解決了
但還是需要 operator int()  回復  更多評論   

<2007年11月>
28293031123
45678910
11121314151617
18192021222324
2526272829301
2345678

導航

統計

常用鏈接

留言簿(3)

隨筆檔案

搜索

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            aa日韩免费精品视频一| 国产精品日韩欧美一区二区三区| 影音先锋亚洲视频| 蜜月aⅴ免费一区二区三区 | 亚洲一区二区在| 艳妇臀荡乳欲伦亚洲一区| 国产精品男女猛烈高潮激情| 香港久久久电影| 久久午夜视频| 在线综合亚洲欧美在线视频| 亚洲在线视频| 亚洲成人资源| 在线视频欧美日韩| 国内视频精品| 亚洲免费观看在线观看| 国产欧美日韩另类视频免费观看| 老司机成人在线视频| 欧美夫妇交换俱乐部在线观看| 亚洲午夜在线| 久久久久一区二区三区| 在线一区欧美| 久久久一二三| 亚洲欧美一级二级三级| 午夜亚洲伦理| 一区二区在线不卡| 欧美大片免费久久精品三p| 欧美国产在线观看| 久久精品在这里| 欧美国产视频一区二区| 久久精品国产亚洲a| 欧美国产日本韩| 久久青青草综合| 国产精品jvid在线观看蜜臀| 欧美韩日视频| 狠狠入ady亚洲精品经典电影| 亚洲人成欧美中文字幕| 国内精品一区二区| 亚洲婷婷免费| 99国产麻豆精品| 久久久久久自在自线| 欧美亚洲视频在线看网址| 欧美国产日韩亚洲一区| 欧美 日韩 国产一区二区在线视频 | 国内外成人在线视频| 日韩亚洲精品视频| 亚洲三级免费观看| 久久久免费av| 久久免费视频观看| 国产精品日产欧美久久久久| 亚洲伦理在线| 亚洲精品午夜| 欧美 日韩 国产 一区| 久久久噜噜噜久久人人看| 国产精品一区二区你懂得 | 欧美大香线蕉线伊人久久国产精品| 国产精品男gay被猛男狂揉视频| 日韩视频一区二区三区在线播放免费观看 | 亚洲视屏在线播放| 欧美激情一区二区在线| 欧美大片免费观看| 最新日韩中文字幕| 欧美成人精品高清在线播放| 欧美成人精品在线| 亚洲国产欧美一区二区三区久久 | 一区二区三区国产在线观看| 亚洲午夜精品视频| 国产精品成人免费视频| 99re亚洲国产精品| 亚洲欧美综合v| 国产精品欧美日韩一区| 亚洲欧美激情四射在线日 | 99成人在线| 欧美日韩午夜视频在线观看| 99亚洲伊人久久精品影院红桃| a91a精品视频在线观看| 一本一本久久a久久精品综合妖精 一本一本久久a久久精品综合麻豆 | 欧美三级中文字幕在线观看| 一区二区三区产品免费精品久久75| 99精品欧美一区二区三区综合在线| 欧美另类亚洲| 一区二区三区精品| 久久久久久久999精品视频| 尤物yw午夜国产精品视频明星| 老司机精品视频网站| 亚洲精品乱码久久久久久| 一本色道久久综合狠狠躁篇的优点 | 91久久精品日日躁夜夜躁国产| 亚洲美女在线国产| 国产精品一区二区三区免费观看 | 久久疯狂做爰流白浆xx| 欧美国产免费| 亚洲欧美日韩人成在线播放| 国产亚洲美州欧州综合国| 久久在线免费观看视频| 一本久久精品一区二区| 久久久精品国产99久久精品芒果| 亚洲国产视频a| 国产精品蜜臀在线观看| 久久影院午夜论| 亚洲天堂激情| 亚洲国产精品一区| 欧美伊人久久久久久久久影院| 亚洲高清久久网| 国产精品久久久久免费a∨大胸| 久久国产夜色精品鲁鲁99| 日韩一区二区精品| 开心色5月久久精品| 亚洲午夜一区二区三区| 亚洲国产精品v| 国产一区二区电影在线观看| 欧美精品久久久久久久免费观看| 欧美一区=区| 亚洲无亚洲人成网站77777| 亚洲电影免费观看高清完整版在线观看 | 欧美黄色免费网站| 欧美在线综合| 亚洲视频在线一区观看| 亚洲激情在线| 欧美成人午夜77777| 久久精品国产99精品国产亚洲性色 | 99热免费精品在线观看| 影音先锋日韩资源| 国产欧美视频一区二区三区| 欧美日韩成人激情| 欧美国产日韩一区二区| 久久免费高清| 久久精品视频导航| 欧美一区二区三区在线观看视频| 一本色道久久综合| 亚洲精品一区在线观看| 亚洲国产裸拍裸体视频在线观看乱了中文| 久久激情视频免费观看| 性欧美xxxx大乳国产app| 亚洲一区二区三区四区五区黄| 亚洲电影第1页| 久久久精品一品道一区| 久久亚洲午夜电影| 久久久亚洲综合| 香蕉久久一区二区不卡无毒影院 | 国产精品日日做人人爱| 欧美三级韩国三级日本三斤| 欧美另类高清视频在线| 欧美人成免费网站| 欧美日本中文字幕| 欧美日韩大片| 欧美日韩一区二区在线观看| 欧美日韩一区二区精品| 欧美色图五月天| 国产精品久久久久久久久久直播 | 欧美日韩精品一区| 欧美视频免费在线| 国产精品毛片高清在线完整版| 国产精品女主播在线观看| 国产精品视频在线观看| 国产一区二区久久久| 激情综合自拍| 亚洲精品少妇| 亚洲一区尤物| 久久久噜噜噜久久| 亚洲国产精品一区| 亚洲私拍自拍| 久久久久九九九| 欧美国产先锋| 国产精品久久久久三级| 韩国一区二区三区在线观看| 亚洲精品麻豆| 香蕉av福利精品导航| 裸体素人女欧美日韩| 91久久精品国产91性色| 亚洲一区精彩视频| 久久久精品视频成人| 欧美日韩在线播放一区| 国产自产2019最新不卡| 亚洲免费av电影| 久久精品亚洲| 亚洲免费成人av| 久久精品五月| 国产精品v欧美精品v日韩精品| 韩国av一区| 亚洲一区综合| 欧美激情视频在线播放 | 久久综合一区二区三区| 欧美日韩一区不卡| 亚洲电影在线观看| 亚洲欧美日本在线| 亚洲国产精品一区二区第四页av | 99精品99| 久久综合九色综合欧美狠狠| 欧美午夜精彩| 亚洲国产成人精品女人久久久| 性欧美激情精品| 亚洲日本成人| 开心色5月久久精品| 国产精品视区| 亚洲一区二区三| 亚洲国内精品在线| 老妇喷水一区二区三区| 国产欧美精品国产国产专区| 亚洲综合第一页| 亚洲三级免费电影|