ZZ C 列舉型別的定義域問題

c++ 中的列舉型別繼承於 c 語言。就像其他從 c 語言繼承過來的很多特性一樣，c++ 列舉也有缺點，這其中最顯著的莫過於作用域問題——在列舉型別中定義的常量，屬於定義列舉的作用域，而不屬於這個列舉型別。例如下面的示例：

enum fileaccess ;

fileaccess access = ::read; // 正確

fileaccess access = fileaccess::read; // 錯誤

c++列舉的這個特點對於習慣物件導向和作用域概念的人來說是不可接受的。首先，fileaccess::read 顯然更加符合程式設計師的直覺，因為上面的列舉定義理應等價於如下的定義（實際上，.net 中的列舉型別便是如此實現的）：

class fileaccess ;

其次，這導致我們無法在同乙個作用域中定義兩個同樣名稱的列舉值。也就是說，以下的**是編譯錯誤：

enum fileaccess ;

enum fileshare ;

如果這一點沒有讓你惱怒過的話，你可能還沒寫過多少 c++ ** :-)。實際上，在最新的 c++0x 標準草案中有關於列舉作用域問題的提案，但最終的解決方案會是怎樣的就無法未卜先知了，畢竟對於象 c++ 這樣使用廣泛的語言來說，任何特性的增刪和修改都必須十分小心謹慎。

當然，我們可以使用一些迂迴的方法來解決這個問題（c++ 總是能給我們很多驚喜和意外）。例如，我們可以把列舉值放在乙個結構裡，並使用運算子過載來逼近列舉的特性：

struct fileaccess ;

__enum _value; // 列舉值

fileaccess(int value = 0) : _value((__enum)value) {}

fileaccess& operator=(int value)

operator int() const

}; 我們現在可以按照希望的方式使用這個列舉型別：

fileaccess access = fileaccess::read;

並且，因為我們提供了到 int 型別的轉換運算子，因此在需要 int 的地方都可以使用它，例如 switch 語句：

switch (access)

當然我們不願意每次都手工編寫這樣的結構。通過使用巨集，我們可以很容易做到這一點：

#define declare_enum(e) struct e e& operator=(int value) operator int() const enum __enum ; private: __enum _value; };

我們現在可以按如下的方式定義前面的列舉，並且不比直接寫 enum 複雜多少。

declare_enum(fileaccess)

read = 0x1,

write = 0x2,

end_enum()

declare_enum(fileshare)

read = 0x1,

write = 0x2,

end_enum()

還有一些列舉型可以盡量寫在某個類的定義內