Overriding int on a bit enum

Question

I saw some .NET 2.0 code which looked like this:

 public enum abc : int
 {
  value1 = 1,
  value2 = 2,
  value3 = 4
 }

etc...

Now I know the flags enum can be used for bit values (like above, right?) so you can do | "or" &, etc, but what is the reason for not using that? What is the point in overriding int?

If I design an enum for choosing multiple values I would use the flags attribute and not override anything (what I don't understand). What does the above approach net?

Thanks

Answer 1

It's not "overriding" int , it's indicating what type the enumeration is based on. The default is int so this actually isn't achieving anything, but in some cases you might want to base an enum on long to store more flags, or byte to save space if there will be very many instances of the enum around and it only has a few values, however the recommendation in the framework design guidelines is to use int unless you have a very good reason not to.

If this is intended to be a flags enumeration then it should be marked with [Flags] , and this appears to be the intention here, so the omission looks like a mistake. You can still combine the values using the bitwise operators even if it isn't marked with [Flags] , but from memory I think you get a compiler warning (or it might be an FxCop warning, or possibly a ReSharper warning...).

Answer 2

The ": int" is specifying what to use as the underlying type for enum values; any integral type other than char can be used here. The default is int, so it is redundant in this case.

Answer 3

FlagsAttribute only tells the user that fields in this enum can be combined; it doesn't actually set the fields of the enum to "flaggable" values. This, you will have to do yourself, just like you have already.

Answer 4

I don't see any benefit. Probably lack of experience on the programmer's part.

Answer 5

If you are asking the scenario for choosing specific values, I don't know a good example offhand, but I can imagine something like

enum Color = {
  Red = 0xFF0000,
  Green = 0x00FF00,
  Blue = 0x0000FF }

maybe being useful.

Answer 6

Setting the values on a non-Flags enum to use a 1-hot encoding just for the sake of using a 1-hot encoding doesn't really make any sense. I guess it might make sense if you thought you might make it a Flags enum in the future. Otherwise, the values should either be not overridden or assigned a value based on their meaning (eg. Color.Red = 0xFF0000).

Answer 7

In reference to the ": int" specifying the underlying type, if I saw that, I'd have a look around and see if they delcare all their enums that way. If so, they probably just learnt to write enums that way ( or maybe they are a hyper-explicit coder). If however, just this enum was declared this way, perhaps the programmer is trying to say something (that might have been better said with a comment) that it is critical that this has an underlying "int" type. Perhaps it is being binary serialised or deserialised somewhere.

As for the [Flags] attribute, as far as C# is concerned, you can use bitwise operators on any enum, not just those declared with [Flags]. From your above example, without any [Flags], the following is totally legal:

abc myAbcValue = value1 | value2;

The primary difference with respect to the [Flags] is in the ToString() and Parse() methods of Enum. Without [Flags], myAbvValue.ToString() will return "3", but with [Flags] it will return "value1, value2". Likewise, with the [Flags],

abc yourAbcValue = (abc)Enum.Parse( typeof(abc), "value1, value2") ;

will set the underlying value of yourAbcValue to 3.

Note that the IsDefined() method of Enum() does not allow for multiple values with [Flags] enums, so:

Enum.IsDefined( typeof(abc), "value1, value2")

returns false regardless of the use of [Flags].

Also note that [Flags] provides information for any reflection access, and other languages may treat the restriction on flagged enums differntly to normal enums.