C# Behind the Scenes
I found it surprising that people still don't understand how iterators and anonymous methods work in C# in Whidbey. I guess it takes my reading a new blog post every week to realize that not everyone has read the C# 2.0 specification. It's all in there, and it's not as dry as you might imagine. There's no need to peek inside the assembly via ILDASM (Reflector's a better choice).
I will actually be writing up a series of blog posts on these new features shortly (i guess that I am tiring of generics), and demonstrate how these features, especially iterators, can used beyond their original intentions.
In college, I used to poured through (for enjoyment) every line of the whole C++ Annotated Reference Manual by Bjarne Stroustrop and, later, I would follow articles in C++ User Journal and other journals written by members of the standards committee. These ordinarily would be consider very dry, arcane articles, but I got a kick out of seeing how function calls were resolved, and how the standard chooses among various syntactical ambiguities such as that between constructor-style initialized declarators and function calls.
I soon developed a distaste for C++, though, because the various shortcuts (through operator overloading, deterministic finalizations and so on) offered in language didn't compensate for the verbosity of declaring functions twice (one in the header files and one in the source file), the need to write overload countless operators (C++ did not have the smarts to infer postfix, assignment operator overloading for example). Didn't C used to emphasize brevity? C++ was also moving closer to obfuscation, although not quite as bad as Perl, and I was tiring of managing memory manually.
C# came along (preempting my move to Java), and I was immediately drawn to its emphasis on productivity for a modest loss of power. The one thing that I miss in C# is C++'s outstanding template capability, especially useful for template metaprogramming. There are some really nice libraries such as Boost that make use of this, not to belittle STL. Generics in C# lacks specialization, static method calls (useful for overloading) and the ability to call arbitrary methods by name. There is actually an clever but indirect technique to implement all these technique through the use of generic statics; Comparer<T> uses such an approach. (More on that in a later post.)
These techniques in C++ may appear in later versions of CLR, such as through the ability to constrain generic classes based on "patterns" rather than "interfaces," according to a C# team member I met in a recent NETDA user meeting. "Patterns," I am guessing, are like interfaces, but do not have to be defined in the target class. The runtime probably dynamically paints an interface into a class, whose members that matches the pattern.