The nature of the enum type

Original address: http://www.cppblog.com/chemz/archive/2007/06/05/25578.html

To the beginning of the C language enum type is used as a user-defined method for the finite set constants of the class is introduced into the language
, and was once the only way to define compile-time constants in C + + (later, a static integer constant was introduced into the class).
According to the description of the enum type above, exactly what type is the type defined by the enum? As
What is the amount of memory space that a user-defined type consumes? Does using the enum type really make a limited
What about the boundary constraints of set constants? You may all know that the enum type and int type have rules for implicit (automatic) conversions.
Is it really possible to use an enum-type variable instead of an int type variable anywhere? The following will be individually
Answer these questions.
1. What type is the type defined by the enum?
In C + + we all know that there are only two large types of categories: Pod Type and class type (unclear can be
See my other articles). The type defined by the enum actually belongs to the pod type, which means that it participates in the pod
The implicit conversion of the type of the enum to the type of int.
That is, the type defined by the enum does not have a namespace-qualified capability (because it is not part of a class type).
Its defined constant quantum has the same visibility as the enum type's namespace, because it has no name
Limited ability, so there will be a name conflict phenomenon. Such as:
struct Cetype
{
Enum EType1 {e1, E2};
Enum EType2 {e1, E2};
};
In the above example, the E1, E2 name conflict compile-time error occurs because the enumerator (E1, E2) is
The name in the Cetype namespace, also in the enumeration that references the Cetype, must take cetype::e1
This is done in a way that is not cetype::etype1::e1 to reference.
2. As a user-defined type what is the amount of memory space it occupies?
The problem is that sizeof (EType1) equals the question of how much, is not every user-defined enumeration class
Types have the same size? In most 32-bit compilers (e.g. VC + +, GCC, etc.) an enumeration class
The size of the type is actually a sizeof (int) size, is the size of the enumeration type really should be an int
Type of size? In fact, this is not the case, in the C + + standard document (ISO14882) is not defined,
This is stated in the standard: "The size of an enumeration type is the size of an integer that can hold the value of the maximum enumerator",
The standard also says: "The value of an enumerator in an enumeration type must be able to be expressed in an int type",
That is, the size of the enumeration type cannot exceed the size of the int type, but is not required and the int type
Have the same size? The above criteria have been made clear, as long as the largest enumerator can accommodate the
The integer of the value is available, so it can be char, short, and Int. For example:
Enum EType1 {e1 = Char_max};
Enum EType2 {e2 = Shrt_max};
Enum EType3 {e3 = Int_max};
The above three enumeration types can be represented in the memory space of char, short, and int, respectively:
sizeof (EType1) = = sizeof (char);
sizeof (EType2) = = sizeof (short);
sizeof (EType3) = = sizeof (int);
So why would the 32-bit compiler compile the dimensions of the above three enumerated types into the size of an int type?
Mainly from the 32-bit data memory to consider the requirements of its aspects, in some computer hardware environment with the
(e.g. Sun SPARC), some are due to a complete 32-bit word-length CPU
The reason for the very high efficiency (for example: IA32). So it is not easy to assume that the size of an enumeration type is an int class
Size, you might encounter a compiler that uses the above processing strategy to conserve memory.
3. Can the enum type really be used to constrain the bounds of a finite set constant?
First look at the following example:

enumEType {e1 =0, E2};voidfunc1 (EType e) {if(E = =E1) {           //Do something      }               //Do something because E! = E1 must e = = E2}voidFunc2 (EType e) {if(E = =E1) {          //Do something     }     Else if(E = =E2) {          //Do something}} func1 ( static_cast <EType> (2)); Func2 ( static_cast <EType> (-1) );

The above code should clearly illustrate such an unusual situation, in the use of a range of the entire
Type value calls the FUNC1 function causes the function to take the behavior that should not be taken, and the second function may be a little better
He simply ignores values that are out of range. This means that the type defined by the enumeration is not a really strong type
A limited set of constants, such that a condition and the two function arguments above are declared as integer types without
Any differences. So be aware of the pitfalls of enumerated types in the standard definitions. (In fact, only the class type is true
Positive strong type)

4. Is it really possible to use a variable of type enum in place of an int type variable anywhere?
In the above discussion, there is too much consistency and interchangeability between the variables of the enumerated type and the integer variables.
So is it possible to use enum type as an alternative to each type of int?
In fact, this is not the case, after all, the enumeration type is a type that can be distinguished at compile time, and the 2nd analysis
Enumeration types do not necessarily have the same dimensions as int types, and these two differences determine that in some cases it is not
To use the enumeration type instead of the int type. Such as:
First case:
Enum EType {e1 = 0, E2, E3};
EType Val;
Std::cin >> Val;
Second case:
Enum EType {e1 = 0, E2, E3};
EType Val;
STD::SCANF ("%d", &val);
The above two cases are basically the same type of problem, not actually. The first case will cause
Compile-time error, because Std::cin does not define an overload >> operator for the corresponding enumeration type, which
The enumeration type is an independent and discriminating type, and the second case does not have any compile-time problems.
But it could cause the scanf function stack to be corrupted and make the program run illegally. Above
It has been analyzed that the size of the enum type variable is not necessarily the same as the int type, so we use%d
Is that the enumeration type variable val is treated as a 4-byte int variable and the argument is stacked, while in some
The translator under sizeof (val) equals 1 bytes, so the scanf function will take the next three of the Val variable address
The byte address is also pressed into the stack and assigned, perhaps the three-byte address of the Val variable is not
The special meaning can be rewritten (such as a byte-aligned empty address space), and it may be assumed that he is not wrong
Error, in fact, the SCANF function call after the end of the stack cleanup, which will cause the scanf function
Excessive address space is cleared, which destroys the point of the stack pointer of the peripheral function, which inevitably leads to a process
Sequential run-time error.

There are so many drawbacks to enumerated types by the above description, so how can we have a type-safe enumeration type
It? A class type can actually be used to simulate the concept of a finite constant set of enumerated types, while obtaining the benefits of type safety,

Nature of the enum type (RPM)