Let's just make sure?
-
That's not an horror, just a typical 6pm inattention error! :-D
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
That's not an horror, just a typical 6pm inattention error! :-D
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
That's not an horror, just a typical 6pm inattention error! That shoud be scary - I mean, to work for a company, where at 6 p.m. enum values can jump out of enum range. They should also add private void method(bool b) { if (currenttime>=6pm) { if (b!=true && b!=false) { throw new After6pmException(); } } }
-
That's not an horror, just a typical 6pm inattention error! That shoud be scary - I mean, to work for a company, where at 6 p.m. enum values can jump out of enum range. They should also add private void method(bool b) { if (currenttime>=6pm) { if (b!=true && b!=false) { throw new After6pmException(); } } }
Management should learn not to overwork their staff!! :-)
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
modified on Wednesday, December 16, 2009 5:57 PM
-
That's not an horror, just a typical 6pm inattention error! That shoud be scary - I mean, to work for a company, where at 6 p.m. enum values can jump out of enum range. They should also add private void method(bool b) { if (currenttime>=6pm) { if (b!=true && b!=false) { throw new After6pmException(); } } }
Joke aside there plenty of case when an Emun value can be outside the normal value of the Enum. From the top of my head here are 3 valid example - when use as Flag / bit wise value - when the value is cast from a random int - when the value comes from serialization of a different version
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Joke aside there plenty of case when an Emun value can be outside the normal value of the Enum. From the top of my head here are 3 valid example - when use as Flag / bit wise value - when the value is cast from a random int - when the value comes from serialization of a different version
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
Thank you. For some reason I was sure C# cares at least a little bit what do you assign to enum variable. You are right, it does not. Good thing is - I learned something new.
-
Thank you. For some reason I was sure C# cares at least a little bit what do you assign to enum variable. You are right, it does not. Good thing is - I learned something new.
Member 357537 wrote:
Thank you. For some reason I was sure C# cares at least a little bit what do you assign to enum variable. You are right, it does not. Good thing is - I learned something new.
Me too. I had always assumed that it would check the value being assigned to an enum variable. In fact, it does not and any old int will do. I come from a Java background and I just took it for granted that C# would do the same sort of check as Java. In Java, it checks to make sure that you can only use one of the defined enum values, and anything else gives an error (enums in Java are not integers, they are a type in their own right so you cannot simply cast an integer to an enum). I have to say I'm shocked. I'm sure someone will come up with a reason why you can use any old random integer value in C# but it seems a bit sloppy to me. After all, part of the reason for using enums is to constrain the range of values.
-
Member 357537 wrote:
Thank you. For some reason I was sure C# cares at least a little bit what do you assign to enum variable. You are right, it does not. Good thing is - I learned something new.
Me too. I had always assumed that it would check the value being assigned to an enum variable. In fact, it does not and any old int will do. I come from a Java background and I just took it for granted that C# would do the same sort of check as Java. In Java, it checks to make sure that you can only use one of the defined enum values, and anything else gives an error (enums in Java are not integers, they are a type in their own right so you cannot simply cast an integer to an enum). I have to say I'm shocked. I'm sure someone will come up with a reason why you can use any old random integer value in C# but it seems a bit sloppy to me. After all, part of the reason for using enums is to constrain the range of values.
It's easy, the FLAGS ! If your enum is enum MyEnum{ flag1 = 1, flag2 = 2, flag3 = 4, flag4 = 8, } And if you set everything ON (MyEnum = 15), the value is valid but not in the range. I think thats the reason why :) Merry Christmas !
-
It's easy, the FLAGS ! If your enum is enum MyEnum{ flag1 = 1, flag2 = 2, flag3 = 4, flag4 = 8, } And if you set everything ON (MyEnum = 15), the value is valid but not in the range. I think thats the reason why :) Merry Christmas !
Yes and if the enum values are all disjoint - like they are for a set of flags or possibly for a field in a binary structure - then the code to validate the value would essentially have to do a search every time an enum is assigned. That's a tax I would not want to have to pay just because other developers can't be trusted. (As if I were perfect...) And the enum-as-flag idiom comes from C++ where the only way to declare a const int value in a class scope was to use an enum. Bonus info: The compiler I use (Microsoft C++) lets you declare the size of the integer underlying the enum. So for case where I need more than 32 flags, I can write:
enum MyBigEnum : __int64 {
MBE_Unknown = 0,
MBE_QualityFlag = 0x0000000001,
MBE_EnergyFlag = 0x0000000002,
// ...
MBE_MyLastFlag = 0x4000000000,
};-- T
-
Yes and if the enum values are all disjoint - like they are for a set of flags or possibly for a field in a binary structure - then the code to validate the value would essentially have to do a search every time an enum is assigned. That's a tax I would not want to have to pay just because other developers can't be trusted. (As if I were perfect...) And the enum-as-flag idiom comes from C++ where the only way to declare a const int value in a class scope was to use an enum. Bonus info: The compiler I use (Microsoft C++) lets you declare the size of the integer underlying the enum. So for case where I need more than 32 flags, I can write:
enum MyBigEnum : __int64 {
MBE_Unknown = 0,
MBE_QualityFlag = 0x0000000001,
MBE_EnergyFlag = 0x0000000002,
// ...
MBE_MyLastFlag = 0x4000000000,
};-- T
-
Member 357537 wrote:
Thank you. For some reason I was sure C# cares at least a little bit what do you assign to enum variable. You are right, it does not. Good thing is - I learned something new.
Me too. I had always assumed that it would check the value being assigned to an enum variable. In fact, it does not and any old int will do. I come from a Java background and I just took it for granted that C# would do the same sort of check as Java. In Java, it checks to make sure that you can only use one of the defined enum values, and anything else gives an error (enums in Java are not integers, they are a type in their own right so you cannot simply cast an integer to an enum). I have to say I'm shocked. I'm sure someone will come up with a reason why you can use any old random integer value in C# but it seems a bit sloppy to me. After all, part of the reason for using enums is to constrain the range of values.
David Skelly wrote:
part of the reason for using enums is to constrain the range of values
It is indeed. But I think C# strikes the right balance; another reason for using enums is that it provides a more readable alternative to hard-coded ints and a more efficient alternative to string literals. C# does not allow implicit casts to enum values, precisely because it is unsafe. There is no run-time check when explicitly casting because it would introduce significant overhead. I find it rather too strict if Java as you claim does not allow casting to enum types from integer types. Imagine you have a class with many fields that each have a small predefined set of legal values. We can define enums to represent these sets, use byte as the base value, and store such data in a database using one byte per attribute. Storing the names is extremely inefficient: Each column has to be sized according to the maximum length permitted in the set of values. You'd easily go to 20 characters in many cases, and sometimes more, which depending on encoding will require 20 to 40 bytes of storage space. If you have five such fields, you could end up using 200 bytes instead of 5. And large row size == bad performance. If you can't cast to enum values, you'd have to write switches instead (switch (value) { case 1: return CreditCard.MasterCard; break; ...}) which is pretty boring work!