Jaa

More peculiarites of enum

  • Artikkeli

The well known (or moderately known fact): C# enums can contain any value supported by its base type and not just the ones specified in the enum. Lets consider the following enum.

 enum WeekDay
{
    Monday = 1,
    Tuesday = 2,
    Wednesday = 3,
    Thursday = 4,
    Friday = 5,
    Saturday = 6,
    Sunday = 7
}

Even though the enum supports values from 1 to 7 you can do the following.

 WeekDay day = (WeekDay)40;
Console.WriteLine(day);

This prints out 40 without any error.

Now comes the lesser known fact: C# 1.2 spec sez "An Implicit enumeration conversion permits the decimal-integer-literal 0 to be converted to enum-type" . This means the following is valid code

 WeekDay day = 0;
Console.WriteLine(day);

Note that even though 0 is not supported it is implicitely casted to the enum!!! No idea why this is supported.

Comments

  • Anonymous
    January 08, 2007
    An enum value of 0 should be always reserved for None, Empty, Default or alike, thus assigning 0 allows to initialize the enum. It should have the same effect as default(MyEnumType)."Do name the zero value of flags enumerations None. For a flags enumeration, the value must always mean all flags are cleared.Note"http://msdn2.microsoft.com/en-us/library/ms229062.aspx

  • Anonymous
    January 08, 2007
    You have pointed to Flags enumeration where it makes perfect sense to have a zero.But in our case this is not a bit flag and there is no default or empty weekday, nor can you have monday and tuesday at the same time (with an OR).

  • Anonymous
    January 08, 2007
    Enumerations are a CLR value type, stored in the method stack as an Int32, which defaults to 0 anyway - the following two code segments have exactly the same end result:WeekDay day;WeekDay day = 0;The C# compiler will however consider the first variable 'unitialised'.

  • Anonymous
    January 09, 2007
    I think it's less to do with the guideline of always defining a enum member with the value 0 than to do with the fact that an enum will always initialize to 0 before the first assignment.  There's really no point in throwing an error for assigning a value (0) to a enum type when that same value was used to initialize it, without error.An in fact, in your example "Weekday day = 0;", the assignment of zero (0) is redundant; day will have been initialized with 0 already.  It could be that this is "supported" because it is optimized out (I'm not sure).

  • Anonymous
    January 16, 2007
    I'm pretty sure it would have to be because (as you mentioned) Enums are used for flags as well as for lists.But of course, a lot of enums come from protocol definitions, so having to mentally add a zero case to every enum would be onerous, for very little extra protection (since enums are initialised to 0, it's not risky like having a zero pointer).

  • Anonymous
    January 20, 2007
    Peter Ritchie:C# requires that you initialize any and all local variables.You are confusing this with member variables that do not have to be initialized.(This is a C# thing, not a CLR/MSIL thing - the CLR, as somebody mentioned, will automatically initialize it if the code does not do that..)

  • Anonymous
    November 23, 2007
    The comment has been removed

  • Anonymous
    December 08, 2007
    they should have make @0 to indicate enum zero.   0 shouldn't be implicitly cast to in any ways, just like any number. VS team should have make this:   if ((myVar & MyEnumName.ColorRed) != 0) to:   if ((myVar & MyEnumName.ColorRed) != @0) so there will be no more implicitly casted zero to enum gotcha :-)

  • Anonymous
    December 08, 2007
    they should have make @0 to indicate enum zero.   0 shouldn't be implicitly cast to in any ways, just like any number. VS team should have make this:   if ((myVar & MyEnumName.ColorRed) != 0) to:   if ((myVar & MyEnumName.ColorRed) != @0) so there will be no more implicitly casted zero to enum gotcha :-)