Consider the following code fragment:

В	Copy Code
__value enum status { fail, pass }; void f( Object* ){ Console::WriteLine("f(Object)\n"); } void f( int ){ Console::WriteLine("f(int)\n"); } int main() { status rslt = fail; f( rslt ); // which f is invoked? }

For the native C++ programmer, the natural answer to the question of which instance of the overloaded f() is invoked is that of f(int). An enum is a symbolic integral constant, and it participates in the standard integral promotions which take precedence in this case. And in fact in Managed Extensions this was the instance to which the call resolves. This caused a number of surprises – not when we used them in a native C++ frame of mind – but when we needed them to interact with the existing BCL (Base Class Library) framework, where an Enum is a class indirectly derived from Object. In the Visual C++ 2005 language design, the instance of f() invoked is that of f(Object^).

The way Visual C++ 2005 has chosen to enforce this is to not support implicit conversions between a CLR enum type and the arithmetic types. This means that any assignment of an object of a CLR enum type to an arithmetic type will require an explicit cast. So, for example, given

В	Copy Code
void f( int );

as a non-overloaded method, in Managed Extensions, the call

В	Copy Code
f( rslt ); // ok: Managed Extensions; error: new syntax

is ok, and the value contained within rslt is implicitly converted into an integer value. In Visual C++ 2005, this call fails to compile. To correctly translate it, we must insert a conversion operator:

В	Copy Code
f( safe_cast<int>( rslt )); // ok: new syntax

One of the changes between the C and C++ languages was the addition in C++ of scope within the struct facility. In C, a struct is just a data aggregate without support of either an interface or an associated scope. This was quite a radical change at the time and was a contentious issue for many new C++ users coming from the C language. The relationship between the native and CLR enum is analogous.

In Managed Extensions, an attempt was made to define weakly injected names for the enumerators of a CLR enum in order to simulate the absence of scope within the native enum. This did not prove successful. The problem is that this causes the enumerators to spill into the global namespace, resulting in difficult to manage name-collisions. In the new syntax, we have conformed to the other CLR languages in supporting scopes within the CLR enum.

This means that any unqualified use of an enumerator of a CLR enum will not be recognized by the new syntax. Let's look at a real-world example.

В

Copy Code

// Managed Extensions supporting weak injection __gc class XDCMake { public: __value enum _recognizerEnum { UNDEFINED, OPTION_USAGE, XDC0001_ERR_PATH_DOES_NOT_EXIST = 1, XDC0002_ERR_CANNOT_WRITE_TO = 2, XDC0003_ERR_INCLUDE_TAGS_NOT_SUPPORTED = 3, XDC0004_WRN_XML_LOAD_FAILURE = 4, XDC0006_WRN_NONEXISTENT_FILES = 6, }; ListDictionary* optionList; ListDictionary* itagList; XDCMake() { optionList = new ListDictionary; // here are the problems … optionList->Add(S"?", __box(OPTION_USAGE)); // (1) optionList->Add(S"help", __box(OPTION_USAGE)); // (2) itagList = new ListDictionary; itagList->Add(S"returns", __box(XDC0004_WRN_XML_LOAD_FAILURE)); // (3) } };

Each of the three unqualified uses of the enumerator names ((1), (2), and (3)) will need to be qualified in the translation to the new syntax in order for the source code to compile. Here is a correct translation of the original source code:

В

Copy Code

ref class XDCMake { public: enum class _recognizerEnum { UNDEFINED, OPTION_USAGE, XDC0001_ERR_PATH_DOES_NOT_EXIST = 1, XDC0002_ERR_CANNOT_WRITE_TO = 2, XDC0003_ERR_INCLUDE_TAGS_NOT_SUPPORTED = 3, XDC0004_WRN_XML_LOAD_FAILURE = 4, XDC0006_WRN_NONEXISTENT_FILES = 6 }; ListDictionary^ optionList; ListDictionary^ itagList; XDCMake() { optionList = gcnew ListDictionary; optionList->Add("?",_recognizerEnum::OPTION_USAGE); // (1) optionList->Add("help",_recognizerEnum::OPTION_USAGE); //(2) itagList = gcnew ListDictionary; itagList->Add( "returns", _recognizerEnum::XDC0004_WRN_XML_LOAD_FAILURE); //(3) } };

This changes the design strategy between a native and a CLR enum. With a CLR enum maintaining an associated scope in Visual C++ 2005, it is neither necessary nor effective to encapsulate the declaration of the enum within a class. This idiom evolved around the time of cfront 2.0 within Bell Laboratories also in order to solve the global name pollution problem.

In the original beta release of the new iostream library by Jerry Schwarz at Bell Laboratories, Jerry did not encapsulate all the associated enums defined for the library, and the common enumerators such as read, write, append, and so on, made it nearly impossible for users to compile their existing code. One solution would have been to mangle the names, such as io_read, io_write, etc. A second solution would have been to modify the language by adding scope to an enum, but this was not practicable at the time. The middle solution was to encapsulate the enum within the class, or class hierarchy, where both the tag name and enumerators of the enum populate the enclosing class scope.) That is, the motivation for placing enums within classes, at least originally, was not philosophical, but a practical response to the global name-space pollution problem.

With the Visual C++ 2005 enum, there is no longer any compelling benefit to encapsulating an enum within a class. In fact, if you look at the System namespaces, you will see that enums, classes, and interfaces all inhabit the same declaration space.

Reference

Concepts