>From: "Bresticker, Shalom" <shalom.bresticker@intel.com> >This is confusing. Doesn't an enum variable already have the type of the >declaration by virtue of the declaration itself? Not quite. While it is effectively a value of the base type for most purposes, it does have the additional property of being of the enum type also. This makes it legal to assign to a variable of that enum type. That would not be legal for a value of the base type that was not of that same enum type. Some of the confusion in the text comes from the strong-typing proponents trying to pretend like the enum isn't just an object of the base type with some extra type checking rules applied. So the text talks about casting the enum to the base type, which is really a no-op; just ignoring the fact that it was officially an enum. Another way of putting it would be to say that an expression operator applied to an enum behaves the same as applying it to an object of the base type, and the result is not an enum. It is irrelevant whether you say that the enum gets cast to the base type and then the operator is applied, or that the operator is applied to the enum and the result of an operator is never an enum. >I don't know how to reconcile these. What is the case being described, >that "the given value is not a member of the enumeration"? Despite the claim of "strong typing" in the LRM, there are a number of ways that an enum object can get a value that is not a member of the enumeration. For example, you can explicitly define an enum whose numeric values are all even numbers, and then use a cast to assign an odd number to it. Or you can define a int enum with 10 members, which get assigned numbers 0-9, put it in a union with an ordinary int, and assign 100 to the int, which puts 100 into the enum int also. Then if you invoke the next() method, the value being given to the method is not a member of the enumeration. This LRM statement then says that the result of next() will be the default initial value for the enumeration. This is X for a 4-state enum, which is what you would expect for an undefined operation. And if you haven't explicitly defined an enum member with an all-X value (which you generally won't), subsequent next() calls will continue to produce X. Steven Sharp sharp@cadence.comReceived on Mon Oct 31 18:24:09 2005
This archive was generated by hypermail 2.1.8 : Mon Oct 31 2005 - 18:25:47 PST