C# underbelly

This week, I came across a post by Brett Schucher on the Object Mentor blog where I found out something very surprising - virtual methods are resolved at compile time with an index of a virtual table indicating the address of the method to call.

Because I don't have a C++ background (or any non-managed code) this part of the underbelly of C# has previously passed me by and I was shocked when I read the post - "this isn't evaluated at runtime?"
My assumption has always been that this was part of the jitter and in fact I hadn't really thought about it that much - after reading a bit about it, frankly I'm still not sure why it was implemented that way... a nod to the past or a technology constraint?

Imagine my surprise when the following day, whilst consuming the delights of Jon Skeet's C# in Depth book the very same subject is referred to in passing when discussing generic method overloads with a cautionary sidebar warning - "Possibly unexpected behaviour!". He describes how the compiler doesn't know what overloads will be available when compiling the generic type and that is is because of the compiler resolving virtual methods rather than execution time resolution occuring.
(If I haven't got that paraphrased correctly, my humble apologies to the almighty Skeet)

Stumbling into this twice in two days - odd indeed.

Suffice to say I feel enlightened somewhat and exposed to some new topics that I can research. I do feel that my lack of knowledge in this are does validate one of Joel Spolsky's themes of the stack overflow podcasts : programmers should learn C. His premise that knowing a lower level language that forces you to know about the nitty-gritty details definitely applies in this case and I feel I really should know more about the core details.

To be honest though, I don't have the time learn a whole new language - I already speak "Dad", "husband" and C# that take up ALL my waking hours.

But I can keep on reading, stay inquisitive and continue being new.

(note: if you haven't come across Jon Skeet's book yet - I recommend it heartily)



0 comments: