CLR eye for C# guy : the beginning

  • Article

So I have been thinking about C#
lately. C# was born together with .Net and it is commonly thought of as a language
that - having little legacy of its own - exposes most of CLR capabilities in a safe
and consistent way. Sure, Managed C++ extensions let you do a bit more with IJW and
such - but then again, IJW was specifically designed for MC++ and is there to make
migration easier.

Overall the perception seems to
be that C# is the "clean slate" .Net language - lean, clean and gives you all you
need... Most samples you can find out there are in C#, and I have heard plenty of
stories involving companies that switched from VB or J++/Java directly to C# despite
the fact that VB.Net and JSharp.Net are available.

This is probably for the best -
as I was saying before, C# has no legacy of its own so it is thought to have been
designed so that no ugly tricks would be needed to translate language contracts into
CLR execution primitives. That's probably true.

What is also true, is that things
are not quite that simple. There are things that CLR can do - safe, non-ugly things
- that C #doesn't expose. There are things
that C# exposes, which CLR is completely unaware of. And it just so happened that
lately I have come across a bunch of examples of those things.

So I decided to start as series
of posts that look into those things - C# syntax, constructs and capabilities and
what they really translate into as far
as CLR is concerned.

I'll probably start with simple
stuff - like method arguments and delegates - and then just see where that goes.

My methodology is going to be pretty
simple - in most cases I'll be writing some C# code, compiling it and "cracking" it
open with ILDASM (IL Disassembler that ships with Microsoft.Net SDK) and see what
things will translate into... and then speculate on the findings of course :) I definitely
don't expect that people reading this will have any deep intimate knowledge of IL
- I don't have that myself - but I'll do my best to make the results self-explanatory.

All my findings are based on a
particular compiler version - namely one shipped with CLR 1.1 v1.1.4322 (also ships
with Vs.Net 2003). While I believe that most things will probably stay they same in
future versions as well, that - of course - may not be true.

Stay tuned...