|
You all know how much I love .NET. And you all pretty much figure I’m a hopeless dinosaur, and I just don’t get it. And you’re all pretty tired of hearing me rant about it. So, sorry… but yes, here’s another one. You may click "back" and get on with your life as appropriate.
<rant>
A recent issue of MSDN magazine had a couple of interesting articles. Check out this one:
CLR Inside Out: managing Object Lifetime
So we all know, one of the key benefits of .NET is that the CLR performs garbage collection. This is probably the most-often cited advantage of C# over C++. (And for that matter, of Java over C++.) Yet here we have an entire article describing something called “the Dispose pattern”, as a way to subvert the CLR’s garbage collection!
The Dispose pattern is a really cool thing – in any object you can implement the IDisposable interface, and then you can call a Dispose method to free the object’s storage. Wow! This is an excellent solution to the pesky problems of garbage collection, wherein you have no control over when dead objects’ storage is released, and you have the storage deletion done in another thread, and you have potential and unpredictable hangs while the garbage collection takes place. You just call Dispose, and poof, the object frees its memory. How great is that?
Back in the old days of C++, we had a similar pattern. We called it delete. But I digress.
Then we have this article:
.NET matters: debugging finalizers
This is a Q&A, and the Q is:
I have a bunch of custom types that, for one reason or another, need to implement IDisposable. I want to make sure that the other developers on my team using this class always dispose of my types correctly. What can I do to warn one of my teammates if he forgets to call Dispose?
I can’t quote the A because it is about ten pages long. The gist of it is that there’s a bunch of caveats you have to worry about if you implement “the Dispose pattern”. You can cause deadlocks, end up with memory leaks, have difficulty debugging destructors, all kinds of fun stuff. All the fun stuff that never happens because you have a garbage collector. Yeah. See the problem with the Dispose pattern is you have to remember to call Dispose.
Back in the old days of C++, we had a similar problem with delete. You had to remember to use it. But I digress.
And finally we have this article:
Bugslayer: Measuring the Impact of View State
This sounds like it wouldn’t have anything to do with memory, but here’s the first paragraph:
Isn't it funny how the Microsoft .NET Framework is thought of as an environment where you don't have to think about memory? Of course, what's one of the number one issues that continues to plague managed applications today? Memory! Why? When the garbage collector runs to reclaim memory, the common language runtime (CLR) suspends all the threads in the application—and no work gets done. When you're not getting any work done, you have a performance problem.
It is really funny that the .NET framework is though of as an environment where you don’t have to think about memory. Hilarious, in fact.
</rant>
Okay, back to debugging some C++. Oleosaurus out.
| 
