Clairfication on Enums

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Before I posted href="">about
enums I talked to a number of folks, but I did not get the full story. style="mso-spacerun: yes">  Prompted by href="">Jeroen Frijters comment I went back and checked
again…. Here is the quote from the Devlead for the JIT\Ngen: prefix = o ns = "urn:schemas-microsoft-com:office:office"

style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">We do in fact load enum
types at JIT time (after all at JIT time we do need to determine if it is an
enum and fetch their values).    Also when enums are used as
parameters to functions we don’t know that they are enums (they look like value
classes in the signatures) unless we look them up (and we load them to determine
this).  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">

style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">

style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thus in the jitted case
the enum will be loaded.   If the module is NGENed, it will also be
loaded but at NGEN time (and then persist the loaded class in the NGEN image).
During execution we will never look at that class, so it does not cost us any
working set memory (or time).  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">

style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">

style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I think it is fair to
say, however that people SHOULD be using Enums.   Any performance
problem associated with them are solvable.  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">So, I was basically right in the
Ngen case and wrong in the JIT case, but I think my overall point still


Comments (17)

  1. Patrick Masterveck says:

    i don’t think so reading the two posts… sorry, your point was wrong.

  2. BradA says:

    So you think we should use ints rather than enums?

  3. Pete says:

    I can’t believe anyone could think the penalties in using enums would outway the benefits (over ints). It’s just inconceivable to me.

  4. To be clear, I absolutely agree with Brad. You *should* use enums instead of magic integers.

  5. Pete says:

    Enums are worth the effort.. has noone though of intellisense?

  6. MartinJ says:

    If I write a function that wants an enum passed into it, the enum is defined in the same assembly, most likely. I wouldn’t think that the cost of checking the enum would be that great. The JIT compiler doesn’t have to search very far to deal with the enum.

  7. Kevin Westhead says:

    The only problem with enums in C#, as I mentioned in the original blog entry and Pete mentioned above, is that there is no intellisense support. The VB editor has much better support for enums than the C# editor, you even get intellisense when writing a Select Case statement against an enum. I think the problem is that people get lazy; it’s easier to type a number that type out the first 4-5 characters of the enum name, followed by CTRL+SPACE to wake up intellisense.

  8. Mujtaba Syed says:

    Enums are a great addition, even if they are loaded into memory while JITing. The slight performance cost is worth it with the readability they lend to the code. They also are a great help to the developer, who instead of remembering magic numbers now can use intellisense (as Pete says; Kevin?).


  9. Kevin Westhead says:

    I should clarify my statement; no intellisense support should read limited intellisense support compared to VB. For example, if I have an enum called MyEnum and I type "MyEnum." then yes, I get a list of the members of MyEnum listed. However, if I have a method that has a MyEnum parameter as follows:

    private void MyMethod(MyEnum en)
    // …

    I’d like to see intellisense for MyEnum when I type "MyMethod(" rather than "MyMethod(MyEnum.".

  10. Pete says:

    Actually I was guessing about intellisense as I don’t use vs.

    Kevin: Surely when you type "MyMethod(" it will show you that the first param needed is a MyEnum? If so you know you have to type "MyEnum." at which point you should get the list?

    I could be wrong though.

  11. Pete says:

    Sorry, this is a bit of an essay but it’s kind of related…

    I have a really odd use of enums that I’m looking for opinions on. I’m trying to wrap UxTheme.dll (theme support for xp) in c# (I’ve seen the codeproject ones — didn’t like them). Unfortunately UxTheme uses a huge number of constants. It has a string representing the "class", then for each class it has a number of constants which are "parts". Each part can have one of many "states" (or share a state group with another part).

    The codeproject wrappers all pretty much use constants, but I decided to use enums. Trouble is, I have almost a tree like structure of these things and I wasn’t sure how to go about it. So I’ve used an enum for all the "classes" (using Richard Blewett’s technique for adding textual representation other than the actual name — see his blog for details) and separate enums for the "parts" of each "class" and still more enums for the different "states". This is a lot of enums 🙂

    In my class that wraps theme support, the "class" is selected at construction (from an enum) and cannot change. I need a way of letting the user specify and change the "part" for this "class" (given that there are lots of "part" enums) — I could only come up with the approach of having an overridden Set method (SetPart) for every one of the "part" enums, and many more Set methods (SetState) for all the "state" enums.

    My other solution is the bit I need help with. I use a custom attribute "LinkedToEnumAttribute" in the "class" enum that specifies for each class which "part" enum it corresponds to. I then provide a static method (in a separate "LinkedEnum" class) to find whether or not a selected part enum is legal for the given "class". I also use this approach for states.

    Now I only have one method to set the part (and one to set state). It takes a generic Enum and tests for an appropriate link and throws "InvalidEnumException" (or whatever it’s called) if it doesn’t correspond. Is this a good approach? I think it scales a little better than overridden methods for every type of enum, but I wonder if there’s another approach that I’ve missed?

    I’ll stop here, but if anyone wants more detail I can email code — this has to be the longest blog comment ever 🙂

  12. Kevin Westhead says:

    Pete: That’s exactly right, but because I’m lazy <g> I don’t even want to type "MyEnum." I’d just like the list of all MyEnum members to appear straight away.

  13. Pete says:

    Is it not possible to write a small extension for vs to do what you want? Something like if the parameter (from intellisense) is a MyEnum then automatically put "MyEnum." at the cursor (thereby triggering the intellisense for the enum)?

  14. Mark Levison says:

    Not really realted to the enum’s topic.

    Could you post a complete copy of the evolving design guidelines? We are trying to use all of the design Guidelines (old and new), so its a bit of pain having to come to read the weblog to check the new ones. (Impossible during a code inspection).


  15. Brad Abrams says:

    Good discussion… I will make sure the VS guys get this info….
    On the DG in doc format, it is a common request, but there are a number of issues to over come internally. But let me see what I can do.

  16. Well, we have not discussed one point where automatically expanding to MyEnum. would be bad. If the method is overloaded, then the user first needs to decide which method to choose first. The method s/he chooses might not be the one which takes MyEnum as the first parameter. So, if this is the case, and VS already has expanded to "MyEnum." then the user needs to delete it.

    However, if there are no other overloads, then I would prefer the code to be automatically expanded to "MyEnum.". On a side-note, in the first case, if the user decides to choose some other overloaded method, then if VS decides to delete the expanded "MyEnum." then it will be a great feature to have.

  17. Kevin Westhead says:

    I think that you make a good point about the overloaded case, however there are still plenty of places where this feature is useful, e.g.

    MyEnum en = <list pops up>

    if (en == <list pops up>

    switch (en)
    case <list pops up>