Monday 28 May 2012

Interesting stuff from these last months

It's been a long while since my last post of the kind "last month's interesting stuff", but I have several interesting things from the last months that I'd like to "serialize" and that I've not been able to fit into any other entry, so here it goes a new mash up.

  • Good question in Stack Overflow about "Utility methods"
  • Astonishing article comparing C# closures with Java pseudo closures http://csharpindepth.com/Articles/Chapter5/Closures.aspx
  • Excellent write up about the usage of GPU's for General Computation
  • .Net IL (bytecodes) has to instructions for calling methods call and callvirt. Contrary to what you could expect, for most of the non virtual method invocations, callvirt is used instead of call. Yes, sounds confusing, but there's a good explanation here. Slightly related to that, you can read here some thoughts about the overuse of virtual
  • I found by chance this excellent answer to a question I had asked myself many years ago but for which I never got to devote any thinking or even googling: Why a C# struct cannot be inherited?

    Technically, being a "value type" means that the entire struct - all of it's contents - are (usually) stored wherever you have a variable or member of that type. As a local variable or function parameter, that means on the stack. For member variables, that means stored entirely as part of the object. That means that if you allowed structs to have subtypes with more members, anything storing that struct type would take up a variable amount of memory based on which subtype it ended up containing, which would be an allocation nightmare. An object of a given class would no longer have a constant, known size at compile time and the same would be true for stack frames of any method call. This does not happen for objects, which have storage allocated on the heap and instead have constant-sized references to that storage on the stack or inside other objects.

No comments:

Post a Comment