The garbage collector?!??

vis781

Well-known member
Joined
Aug 30, 2005
Messages
2,016
Location
Cambridge, UK
Programming Experience
5-10
Ok i thought it might be nice to get some laid back opinions from the people on this forum about the garbage collector. Here is how i see it. It is there but not understood. It's frankly shrouded in cryptic articles from MS yet when we go to make classes we are supposed to be able to use related methods..

Finalize
Dispose
SupressFinalize

I have done much reading on the GC in the hope to understand just when it will collect, what generation it is collecting etc.. Lets face it it's actions are not random. It does a good job, but how are we to do a good job of creating classes that must be disposed of if we don't know just when it's going to be doing it's rounds. We are provided with a method for calling the garbage collector to reclaim memory and then advised not to use it. What gives? It plays a pivotal role in all our apps and can be the difference between having an app with good performance or poor performance.
I have met programmers who guess, i have met programmers who have spend hours watching the performance of their app trying to work out why it slows down in places. Is it just a given that we are subject to a whim of MS and something that we all should accept or does anyone truly understand what is, to my mind, the biggest mystery of .net.
 
IMHO, you shouldn't worry about the Garbage Collector! If your class has resources that need to be cleaned up then you should implement IDisposable.

Simple rule of thumb: If you are using a class that has a .Dispose method, you should call it.
 
It was my understanding that the only time .Dispose was necessary was if you are using unmanaged resources.

But for 99% of the time, the GC isn't something that needs to be worried about. That was kinda the point of the GC.

-tg
 
Yes but what i'm talking about it when you create a class that you have decided will implement the idisposable interface. So to everyone it's just a sub where you do the clean up right, so how do you decide whether or not to use SupressFinalze or finalize. I have read the articles and it is still no clearer to me. I also tend to disagree that it should not be worried about. If we are creating objects should we not be just as concerned about how they are destroyed and when?
 
Depends.... managed code? Or unmanaged code? If using 100% managed code, no, not really. You just have to take it on faith that it will be done. Does it matter if it's in 5 seconds, or 5 minutes? In most cases it doesn't. Now, there may be cases where it does matter, but I think those a few and far between. And maybe you do care. In which case, if the object has a .Dispose method, call it. But if you are designing the object, there;s nothing to force a developer using your object to call your .Dispose method.

-tg
 
I don't think that i have made my query clear. Consider

VB.NET:
Public Class I-Use-A-Lot-Of-Resources
Implements IDisposable
 
Public Sub Dispose Implements IDisposable.Dispose
 
'Do clean Up
 
End sub
 
Sub Finalize...
 
End sub

Pretty straight forward right? But no if this class uses resources that also implement the idisposable interface does this then mean that you would have to suppress this finalize method or do the first clear up there.


This is what i'm trying to ask. Does anyone really understand how the GC works and what roles these methods play? My point is that having read the scarce articles i don't think it is very well explained. Unmanaged or managed? doesn't matter the GC still has to do it's job.
As developers we create classes all the time some may need to implement idisposable some may not but the documentation should be clear on how to correctly implement and use that method and the other methods that can affect how our new class/object is disposed of. Maybe we shoudn't care and remain oblivious to it's actions?
 
Back
Top