Things I learnt reading C# specifications (2)


The story so far: After reading Jon Skeet’s excellent C# in Depth - again I’ve decide to try and actually read the C# language specification
You can read about in a previous post of mine:
Things I learnt reading C# specifications (#1)
And so as I continue to read the C# specifications along with the excellent comments by many industry leaders (I own the annotated version) and I keep discovering cool stuff about the language I’ve been using for more then a decade.
And so here is the second list of things I found out while reading the C# specifications:

args can never be null

Any .NET developer who ever created a console application knows what I’m talking about – there’s always a Main method with one of the four possible signatures:
Two of which pass the command line arguments (if any) used.
I’ve always was a bit defensive about the args maybe due to scars I have from writing C++ programs - although in C++ args would never be NULL but that’s a different story.
In any case according to the C# specs:
The string[] argument is never null, but may have length of zero if no command-line arguments were specified
So there you have it – one less thing to check for.

C# uses banker’s rounding

Every needed a value rounded in .NET – it might happen if you use the decimal type or explicitly using Math.Round. Ever wondered what would be the result of such round?
The fact is that usually it would behave as expected i.e. round to the closest number (integer) which means 0.9 becomes 1 while 4.2 becomes 4. But what happens when rounding half a number would it round or down?
The answer is “it depends” -  in fact both 42.5 and 41.5 would be rounded to 42!
This rounding happens mostly due to the fact that it’s the answer for the ultimate question but also because the rounding method used rounds to the closest even number. Known as the Banker’s rounding and it’s has many nice properties:
Over the course of many roundings performed, you will average out that all .5's end up rounding equally up and down. This gives better estimations of actual results if you are for instance, adding a bunch of rounded numbers. I would say that even though it isn't what some may expect, it's probably the more correct thing to do.
[From StackOverflow]

Boxing and “is” operator

All us .NET developers knows about Boxing & Unboxing, those of us who used the early 1.1 version used them extensively when using collections (we were young and needed the money and besides generics were not implemented yet).
Luckily these days I don’t use boxing/unboxing much but from time to time a value type (e.c. int) needs to be passed as a reference type and Boxing occurs.
But is it still a value type – of course not! it’s a reference wrapping a copy of the value we’ve been using so how come the following code would write “True”?
int myInt = 42;
object aBox = (object) myInt;

Console.WriteLine(aBox is int);

Why’s that? well, it’s part of the specs (4.3) and besides it’s the way I’ve subconsciously expected it to work in fact I’ve been using this behavior without noticing for years -  I had a int and so please don’t confuse me with Boxing because in my eyes it’s still an int.

That’s it for now, I’ll keep reading the specs and probably produce a few more posts on the way when I find interesting facts about the language I’ve been using for more then a decade.

Until then – happy coding…

Labels: , ,