|
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
|
|
|
|
|
Additional bonus info: The underlying size of an enum can be declared in C# (and, presumably, in the other .NET languages as well) in the same way the Microsoft compiler allows enums to have a defined size in C++. So an enum value isn't always an int.
|
|
|
|
|
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!
|
|
|
|
|
Reflector showed me this 'gem' in a contractors project:
string cBRK = Convert.ToChar(int.Parse("13")).ToString() + Convert.ToChar(int.Parse("10")).ToString();
this.ReportStatus("93101Bytes" + cBRK + BytesRecieved.ToString() + cBRK + fileSize.ToString() + cBRK);
kind regards,
JoFli
|
|
|
|
|
I bet, the creator of this is proud of his clever and 'creative' solution... 
blog.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Careful, that might break internationally. I've had issues with one of my users, where his region settings would screw up and the computer would interpret a leading "1" as a "+" (So "13" would be "+3")...
So he SHOULD have added in the proper NumberFormatInfo for invariant culture settings!
(Yes, this is a joke... Sorry, It's the best I can do at 10am)
|
|
|
|
|
Is this called obfuscation?
50-50-90 rule: Anytime I have a 50-50 chance of getting something right, there's a 90% probability I'll get it wrong...!!
|
|
|
|
|
If that's obfuscation, I'm not impressed... If I wanted to make it REALLY confusing, I'd do something like this:
const string blarphnik = "51209576120381929170992";
string elkabong = Convert.ToChar(int.Parse(blarphnik.SubString(1,2))
+ int.Parse(blarphnik .SubString(8 ,1)))
+ Convert.ToChar(int.Parse(blarphnik.SubString(18, 2))
/ int.Parse(blarphnik.SubString(6,1) ));
And then I would publish this as part of a self-help book entitled "How to Drive a Programmer Insane"
|
|
|
|
|
Make the constant string a resource and put the constant ints in the config. 
|
|
|
|
|
No no no... It's harder to hide it that way.
With code like this, you want it buried deeply inside a commonly-used DLL in a not-quite-obsolete language, so when you get laid off and the next guy in line decides to rewrite the code and modernize it, they have a heart attack when they see it.
At least, That was probably what some of my predecessors were thinking...
|
|
|
|
|
Ian Shlasko wrote: It's harder to hide it that way.
No, it hides it in different places; your way has all the information in one place.
Plus, using a resource and config makes it brittle -- if someone changes or removes the entries chaos will ensue.
|
|
|
|
|
Nah, the point is that everything looks normal from the outside... Then you drill down into the utility functions, and each one is completely illegible. So you've already ported half of the library, and now you don't want to touch it because you're afraid you'll miss something and break an edge condition.
|
|
|
|
|
Nice thinking, job security at it's best.
|
|
|
|
|
I should have placed the joke icon. 
50-50-90 rule: Anytime I have a 50-50 chance of getting something right, there's a 90% probability I'll get it wrong...!!
|
|
|
|
|
Tcha! The youth and inexperience shows! Every real programmer knows that the best compression method is to use a random number generator with the correct seed to regenerate the uncompressed file - then all you need to do is send the seed. Extending this:
Random rs;
const string blarphnik = "51209576120381929170992";
int dontTouchThis = int.Parse(blarphnik.Substring(12,1));
rs = new Random(dontTouchThis);
StringBuilder sb = new StringBuilder(2);
sb.Append(Convert.ToChar(rs.Next(15)));
int dontTouchThisEither = int.Parse(blarphnik.Substring(10,1));
rs = new Random(dontTouchThisEither);
sb.Append(Convert.ToChar(rs.Next(15)));
string cBRK = sb.ToString();
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.
This message is made of fully recyclable Zeros and Ones
"Rumour has it that if you play Microsoft CDs backwards you will hear Satanic messages.Worse still, is that if you play them forwards they will install Windows"
|
|
|
|
|
Oh right, I totally forgot about that... But you have to comment your code to make sure it's legible!
Random rs;
const string blarphnik = "51209576120381929170992";
int dontTouchThis = int.Parse(blarphnik.Substring(12,1));
rs = new Random(dontTouchThis );
StringBuilder sb = new StringBuilder(2);
sb.Append(Convert.ToChar(rs.Next(15)));
int dontTouchThisEither = int.Parse(blarphnik.Substring(10,1));
rs = new Random(dontTouchThisEither );
sb.Append(Convert.ToChar(rs.Next(15)));
string cBRK = sb.ToString();
|
|
|
|
|
Ian Shlasko wrote: self-help book
Ian Shlasko wrote: How to Drive a Programmer Insane
So your target audience, precisely, is ...?
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server
|
|
|
|
|
peterchen wrote: So your target audience, precisely, is ...?
I don't think that far ahead
|
|
|
|
|
sane programmers with good reading skills, not a big audience IMO.
|
|
|
|
|
A BASIC developer new to C#?
jofli wrote: Recieved
And maybe didn't graduate high school either? 
|
|
|
|
|
PIEBALDconsult wrote: A BASIC developer new to C#?
No way. Any Basic developer would use either Chr$(13) & Chr$(10) or vbCrLf, both much more readable than the OP.
|
|
|
|
|
PIEBALDconsult wrote: jofli wrote:
Recieved
And maybe didn't graduate high school either? Big Grin
http://www.recieved.co.uk/[^]
Well, at least he tried to use English namings. And I must admit that sometimes it's not that easy, if you're not a native speaker.
|
|
|
|
|
My guess is that this is an artifact of Reflector, not of the original coder.
I do know that in VB, the Chr() function actually does use Convert.ToChar internally so my guess is that C# does the same. Who knows what Environment.NewLine does internally. I assume that the compiler has in-lined the Chr function, and Reflector has simply given you back what the compiler produced. Anyone with too much free time on their hands and a handy copy of Reflector is invited to experiment to find out what the compiler does with this sort of thing.
Reflector is showing you what the code looks like after the compiler has munged it around and played merry havoc with your beautiful code.
|
|
|
|
|
OK, there is no Chr function in C# but you know what I mean.
|
|
|
|
|
The correct code in C# is "\r\n" which is ldstr "\r\n" in MSIL (which is generated exactly like that by the C# compiler)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
