Anyone who has been programming for long enough, will rack up a fair number of languages that they can say they've mastered. When you've done this as I have, then you can't help but have your list of favorites... and then the inevitable comparisons soon follow. You start saying to yourself... God I love this language... but if it only had this or that.

For me I can't help compare C# to C++. I've been programming in C++ since roughly 1996... and have been programming C# since roughly June of last year. Being a full time C# programmer now, I have three main things that I wish I had in C# that existed in C++. Here they are in my order of imporance:
1. Templates. I have to mention this since it doesn't exist in any released form of C#. However, it is coming to C# in the form of Generics with the Whidbey release. Wahoo!
2. const reference parameters. You know... the good old const MyClass& foo construct. I'll probably talk about this in a later post, but I think it is extremely important to any object oriented language, and I'm very upset that this type of construct is missing from C# and probably will continue to be MIA for some time.
3. Deterministic Finalization. Thats what this post is really all about.

.NET doesn't have it. Instead .NET has a garbage collection system that essentially walks the stack whenever memory is low and determines what objects are "unreachable". At that point, those objects are determined to be unreferenced, and are collected, returning their allocated memory back into the pool. This is a very high level view of the process which is quite a bit more complicated. For more details take a look at Inside the Managed Heap on CodeGuru.

What are the implications of this implementation? There are several. First of all, programmers don't have to worry themselves about manually freeing memory with something like the C++ delete operator. Great! However, this comes at a price. We no longer know when our memory will be freed. For those of us who grew up in C++ programming releasing ALL resources in our destructor, this comes as a huge blow. After all, memory is NOT THE ONLY SYSTEM RESOURCE THERE IS! What about database connections? File handles? Windows Handles? What about every other non-managed resources that we may interact with?

Enter IDisposable. Ok, so implement IDisposable.Dispose, and then when you are finished with an object, call Dispose. Problem solved. NOT! How is this any better then delete? Well, if you call Dispose in your finalizer, then you get guaranteed disposal at some time in the future if you forget to do it. So I guess its at least an improvement. However, if you have any high-contention resources... you are still pretty much screwed because you have to depend on a programmer to do something... and we all know how unreliable programmers can be. :)

Ok... so now we've defined the problem. What about a solution? I will have to admit I just thought that the people at Microsoft were a bunch of morons who didn't think about these things. I figured that the CLR guys were all VB programmers or something. As it turns out they did think about it (and as it turns out, a lot of the decision to not implement deterministic finalization was tied to VB - go figure).

However there is hope. Chris Sells (a .NET guru who I have grown to admire more and more every time I read something of his) has been working with ROTOR (the open source CLR implementation released by Microsoft to port to Linux and other platforms) in an attempt to bring deterministic finalization to .NET! Unfortunately they've hit a stumbling block with major performance issues. So if you have the time, stop by Sells Brothers and volunteer to help out. Its a worthy cause!