So, I am currently working with several enumerations with a custom Windows Service that binds to a WebPart through some .NET Remoting calls. I am also using the System.Flags class in order to treat the enumerations as instead of a set of strings or whatever as a set of bit-wise flags, which can easily be seen when using the ToString() method. Basically, it overrides the normal underlying type that is used for the enumeration (such as System.Int32) with System.Byte. This is helpful when using combinations as opposed to building elements that are mutually exculsive. You could accomplish a similiar end result with structs if you convert it to what the embedded system would expect in memory.
In essence it looks like this, you can see that the enum I am delcaring is decorated with the FlagsAttribute:
public enum spSecurityEnum
firstField = 1;
secondField = 2;
But why do it this way? There a lot of reasons why I think bitfields are a decent (notice the word decent being used here) route to go. The most compelling is, while I haven’t actually benchmarked the performance considerations on it, one could assume that because the bit field will take up less memory that it should perform much better. That and I come from a C++ background where bitfields where similiar to that in C#, well, kind of.
But man, am I thinking about reworking this approach to use something like a BitArray with an orthodox enumeration. Although the performance considerations are neat, working with bitfields in C# is turning out to be a pain in the ass in a lot of cases, some of which are carried over compliants from C++ but whatever.
The first thing that I am dying with is the debugger support. Man, for bitfields is it bad to debug your code. When using the immediate window, for the above enumeration I guess I will only see a 2. I guess that is my fault though since I am looking to truncate the code to optimize memory usage, but some sort of visual property to get the former would be sweet, like some sort of visualization representation that will take an enum that has been decorated with the FlagsAttribute and parse out a better representation in the IDE.
My next gripe with bitfields is adding new ones. I really, really wish the refactoring options that are available within Visual Studio would allow you to auto-increment your bitfields if you add a new one in the middle of the enum. I HATE having to go through and rename them all when I find out I have to insert a new one. It is driving me up the wall.
There are other things that I want to complain about, like 32 distinct limits and lack of constructor support for intialization, etc. however those two above are what I would LOVE to see built into Visual Studio are some point which would sway me to continue using bitfields.
Anyways, I am probably going to stick with bitfields for the time being, and I have to check whether Orcas supports these compliants, in which case I should just shut up.