public enum foo : ushort { foo, bar }
ushort test = foo.bar;
Cannot convert from 'Test.foo' to 'ushort'
Sure, I can make variable of type foo, but I'm encoding the value to a network stream, so I want it as a ushort. The thing is, I specifically told the compiler the enum is of type ushort, so why do I have to typecast it
Casting an enumeration that has a defined type..
Ivo Jeglov
Well, one thing I like about C# is strongly typed enums. If I were you, I'd be using one enum for both, assuming they both represent the same thing and have the same values ( which your statement seems to me to imply ).
Beral
Ha! Lucky I only claim to be smarter than bricks and small rodents.
Andrew Toner
Unfortunately, the server side messages will differe from the client side ones, but there is still the possibilty of fitting them all into that 64k space of the ushort, so it may not be so bad (would be neater anyway).
I went to make the overload functions and I saw the reason I didn't... I already have several overloads for other parameters, so all of a sudden I could be looking at 16 variants :(
I guess a redesign of the enum might be in order.
SonGayla
You need to cast it :-)
ushort test = (ushort)foo.bar;
Oh - you said *why* do I have to cast it Because C# is a strongly typed language, IMO it requires casting more often than it really should, but at least it's not VB :P
Junni
I suspected that of being the case, and I wonder if it would be a bad thing if it were changed to inform the compiler of it's internal type. I know I'm dealing with a strongly typed language, but I think this is one step overboard...
Rodel E. Dagumampan
Right. The underlying type specification for the enum only specifies the internal representation of the enumeration (sign and bit-length). It is not an inheritance relationship.
Pebble_Stud
Anujoy08
Well as a I said a few posts up, I have a function that converts the enum member to a ushort for transmission over a network. I have an enum representing server commands and one representing client commands. The function handles both cases. I'm sure I could rewrite the class to have one method for each, but seeing the both work the same way it seemed superfluous to do so. That on the other hand limits from from making the function parameter a specific enum type, though I suppose I could just use an overload, but I come from the old days of minimal code bloat :p
Excubator
Congratulations !!! I need to check if the guy I put forward has been awarded, actually. I should do that now.
Will you get to Seattle next March That would be cool, to meet up.
Sachin K. Singh
Cool. It's 18 hours on planes for me, but I do work for people in Texas and Canada, so it's a flight I'm starting to make regularly. It's in March next year, so you have heaps of time to get ready. In fact, it will be the very end of your award period. I was reawarded for the first time this year.
stevo2005
Yeah, C# goes a few steps overboard IMO.
SDev
Yeah, I agree... at least it isn't VB :p
My gripe with it is that I have a function that accepts more than one enumeration type which are all defined as enum <name> : ushort, so I can't simply make the parameter of type foo and cast it to ushort in the function, I have to cast every call (and there are lots of them) :(
Suzanne Paradis
Well, it doesn't sound like you need a lecture on why you shouldn't write code that relies on so much type-coercion (casting). But I'm curious: why are you
Brian
(PS Recently had a conversation w/ Christian about the pros/cons of C#'s hand-holding.
)
infopete