This is why I am starting to loathe programming
-
Where did you get that idea? The GC does not call Dispose() at all. The GC calls the finalizer, which should, on well-designed code, call Dispose(). I'm talking about languages other than C++ here, though, I'm less familiar with how managed C++ integrates into the .NET garbage collection, and it seems to have some differences from C# or VB.NET. This whole discussion thread is a little bit confused. The basics are this: IDisposable is around to allow you to mark your class as one using resources that should be explicitly released upon finishing with an object, and Dispose() exists to provide a way of doing that explicit resource release. Any class where calling Dispose() is not necessary has no reason to implement IDisposable, so we should always treat IDisposable classes as ones on which Dispose() should be called. Some of the confusion arises because people are talking about "memory leaks". That's not really the issue here, at least not memory that is all allocated for managed objects, because the GC will free that up when it needs to. What you can leak, or just as problematically hold onto indefinitely and cause problems, are all sorts of unmanaged things. Mainly these are things which are scarce or should be held as short a time as possible: locks on a file, connections to a database, huge memory-gobbling outside objects, custom objects that do things which need cleaning up to restore the state of unmanaged things, and so on. Things that, if you only dispose of them in a finalizer, will sit around and potentially block other processes or hold onto possibly important resources until the GC gets around to running your finalizer (even assuming your finalizer disposes of them properly, which it should if you wrote it correctly). The GC doesn't even know about these resources, what they are, how important they are, how big they are, so it isn't going to be triggered in any way by the fact that you're running out of whatever those resources are. Therefore, you will use them up with the danger of them not being freed before they run out or need to be re-used. This sort of thing _could_ result in a memory leak, but only because you could be using some kind of unmanaged resource that is in turn making use of memory. In any case, because the whole purpose of putting a Dispose() method on a class is to add, in a case where deterministic disposal of resources is important, the ability to do so, Dispose() should always be explicitly called on classes that implement IDisposable. That is the main r
and guess what? the default finalizer calls dispose if the class implements IDisposable. So, yeah, indirectly the GC calls Dispose().
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
and guess what? the default finalizer calls dispose if the class implements IDisposable. So, yeah, indirectly the GC calls Dispose().
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/And that's simply incorrect. There is no default finalizer. If you're implementing an IDisposable class, you should make one, and you should have it call your own Dispose() function. Here is a helpful line from MSDN documentation, which confirms both points, that Dispose() is not called automatically and that you have to make your own finalizer and should use it to call Dispose() or do what Dispose() does, lest the GC free up your object without releasing its unmanaged resources: "Because the Dispose method must be called explicitly, objects that implement IDisposable must also implement a finalizer to handle freeing resources when Dispose is not called." You may reference http://msdn.microsoft.com/en-us/library/system.idisposable.dispose%28VS.71%29.aspx[^] for more on the subject.