Not really... Memory management works differently in .NET then in C++.
Object lifetimes are governed by the runtime, and not by the programmer.
Sure, this brings a lot of benifits to the programmer - less likely hood
of memory leaks, dangling pointers, etc. But - it has a bit of an
unfortunate side affect when dealing with unmangaged resources. Since
object lifetimes in .NET are non-deterministic, you the programmer have
to have a way to make sure valuable system resources (file handles,
socket handles, database connections, etc), are returned to the system
in a timely manner.
IDisposable is the way to make that happen. If you have a class that
manages unmanaged resources of some kind, then you should provide a
finalizer for your object (override system.object.finalize). But, that
in and of its self causes issues because of the pressure objects that
override finalize place on the GC. Further, as explained above, GC is a
non-deterministic process - in other words, you have no idea when that
will happen. Sure, you could call GC.Collect your self, but that is not
really a good practice either. IDisposable is your way out. Generally,
on an object that needs a more deterministic lifetime, you would
override System.Object.Finalize AND implement IDisposable. IDisposable
would might look something like:
Public Sub Dispose()
'Do cleanup
System.GC.SuppressFinalize(Me)
End Sub
In this way, if your clients behave and call Dispose - great! They get
early relase of resources, and they don't incure the penalty of having a
object in the finalize queue. But, if they don't behave - at least,
you've made sure the resources will be released - eventually
You may want to read more about the Dispose pattern in the
documentation. The implementation is usually a bit more then what I've
shown, but I wanted to keep it simple.
