C# 4 and .NET 4

314 ❘ ChaPTer 13 memOry mAnAGement And pOinters
As shown, the code implemented in the ~MyClass destructor is wrapped in a try block contained in the
Finalize() method. A call to the parent’s Finalize() method is ensured by placing the call in a finally
block. We discuss try and finally blocks in Chapter 15, “Errors and Exceptions.”
Experienced C++ developers make extensive use of destructors, sometimes not only to clean up resources
but also to provide debugging information or perform other tasks. C# destructors are used far less than
their C++ equivalents. The problem with C# destructors as compared to their C++ counterparts is that
they are nondeterministic. When a C++ object is destroyed, its destructor runs immediately. However,
because of the way the garbage collector works when using C#, there is no way to know when an object’s
destructor will actually execute. Hence, you cannot place any code in the destructor that relies on being run
at a certain time, and you should not rely on the destructor being called for different class instances in any
particular order. When your object is holding scarce and critical resources that need to be freed as soon as
possible, you do not want to wait for garbage collection.
Another problem with C# destructors is that the implementation of a destructor delays the final removal of
an object from memory. Objects that do not have a destructor are removed from memory in one pass of the
garbage collector, but objects that have destructors require two passes to be destroyed: The first pass calls
the destructor without removing the object, and the second pass actually deletes the object. In addition, the
runtime uses a single thread to execute the Finalize() methods of all objects. If you use destructors
frequently, and use them to execute lengthy cleanup tasks, the impact on performance can be noticeable.
The idisposable interface
In C#, the recommended alternative to using a destructor is using the System.IDisposable interface.
The IDisposable interface defines a pattern (with language-level support) that provides a deterministic
mechanism for freeing unmanaged resources and avoids the garbage collector–related problems inherent
with destructors. The IDisposable interface declares a single method named Dispose(), which takes no
parameters and returns void. Here is an implementation for MyClass:
class MyClass: IDisposable
{
public void Dispose()
{
// implementation
}
}
The implementation of Dispose() should explicitly free all unmanaged resources used directly by an object
and call Dispose() on any encapsulated objects that also implement the IDisposable interface. In this
way, the Dispose() method provides precise control over when unmanaged resources are freed.
Suppose that you have a class named ResourceGobbler, which relies on the use of some external resource
and implements IDisposable. If you want to instantiate an instance of this class, use it, and then dispose of
it, you could do it like this:
ResourceGobbler theInstance = new ResourceGobbler();
// do your processing
theInstance.Dispose();
Unfortunately, this code fails to free the resources consumed by theInstance if an exception occurs
during processing, so you should write the code as follows using a try block (which is discussed fully in
Chapter 15):
ResourceGobbler theInstance = null;
try
{
theInstance = new ResourceGobbler();
www.it-ebooks.info