Jason Zander - Discussing the architecture and secrets of .NET and the CLR

I was going to mention the Dispose pattern - this is really under-emphasised in the .NET 1 documentation IMO.  When people talking about deterministic memory management in C++ they are usually talking about deterministic cleanup of the object's internal state - they do a bunch of stuff in the destructor to delete any objects they own among other things. A lot of people come to .NET (and did to Java as well) thinking that finalizers are the equivalent of the C++ destructor and then complaining that they have no control of the calling of the finalizer or even a guarantee that it will ever be called.

If instead you think of Dispose() being the equivalent of the destructor and do all your cleanup there, you call Dispose() on the object instead of using the delete statement, you have almost the same situation you have in C++ - the only difference being that the actual memory isn't freed immediately and I believe there are very few situations were that matters much.

Personally I find the using statement in C# to be rather ugly. I am rather impressed by the way the new C++/CLI implements the Dispose pattern to make your code look like trational C++ with automatic/stack allocation. Jason says in the video that the compiler generates a lot of code to do that but I think that's irrelevant becuase if you wanted the lifetime of the object to be controlled you would have to write that code yourself anyway.

Chris Sells(www.sellsbrothers.com) got a grant from MSR to study about doing refcounting in .NET, using SSCLI/Rotor. Read his/their findings here: http://www.sellsbrothers.com/tools/RotorRefCounting.doc

More interesting is their conclusions, which can be found here: http://www.sellsbrothers.com/writing/refcount_rotor.doc.

Seems like performance is the major problem refcounting introduces.

Lookout is indeed an amazing app!!!

Do you have plans to integrate the functionality of it in the next version of Outlook?  That would be fantastic.

Personally I find the using statement in C# to be rather ugly. I am rather impressed by the way the new C++/CLI implements the Dispose pattern to make your code look like trational C++ with automatic/stack allocation. Jason says in the video that the compiler generates a lot of code to do that but I think that's irrelevant becuase if you wanted the lifetime of the object to be controlled you would have to write that code yourself anyway.


I couldn't disagree more.  Under C++ most destructors were just calling other destructors anyway, and all that's gone with automatic memory management.  Thus classes that hold scarce resources and actually need to be disposed ought to be, and in my experience are, somewhat rare.  I don't mind having syntax to remind me that this class holds a scarce resource.

IU hope the C++/CLI team is smart enough to only provide deterministic finalization of ojects that implement IDisposable, otherwise theyu are generating a look of code for no benefit.

Hmm, you sound like you missed the point of IDispose.

If you have a class that needs to free resources, implement IDispose and free those resources there, calling other object's Dispose() methods if necessary. In C++/CLI, the delete statement calls Dispose on managed objects if they implement IDispose. Additionally it calls it when managed objects allocated automatically go out of scope.

Forget about finalizers - they always were and even more so now are just a last resort. They can free resources for objects were lazy client code forgot to call Dispose() by calling Dispose() themselves, or you could add code to your debug build so that if the finalizer gets called for a class that implements IDispose, it logs an error. Then you can trace what would be memory leaks in the equivalent native C++ code.