258 |
Part II Understanding the C# Language |
Note C++ programmers should note that in C#, you cannot overload new to control allocation.
After you have created an object, you can access its members by using the dot operator (.). For example, the TextBox class includes a member named Text that you can access like this:
message.Text = “People of Earth, your attention please”;
You can make other reference variables refer to the same object:
TextBox messageRef = message;
How many references can you create to an object? As many as you want! This has an im-
pact on the lifetime of an object. The runtime has to keep track of all these references. If the variable message disappears (by going out of scope), other variables (such as messageRef)
might still exist. The lifetime of an object cannot be tied to a particular reference variable. An object can be destroyed and its memory reclaimed only when all the references to it have disappeared.
Note C++ programmers should note that C# does not have a delete operator. The runtime controls when an object is destroyed.
Like object creation, object destruction is a two-phase process. The two phases of destruction exactly mirror the two phases of creation:
1.The runtime has to perform some tidying up. You can control this by writing a destructor.
2.The runtime has to return the memory previously belonging to the object back to the heap; the memory that the object lived in has to be deallocated. You have no control over this phase.
The process of destroying an object and returning memory back to the heap is known as garbage collection.
Writing Destructors
You can use a destructor to perform any tidying up required when an object is garbage collected. A destructor is a special method, a little like a constructor, except that the runtime calls it after the last reference to an object has disappeared. The syntax for writing a destructor is a tilde (~) followed by the name of the class. For example, here’s a simple class that
Chapter 14 Using Garbage Collection and Resource Management |
259 |
counts the number of existing instances by incrementing a static variable in the constructor and decrementing the same static variable in the destructor:
class Tally
{
public Tally()
{
this.instanceCount++;
}
~Tally()
{
this.instanceCount--;
}
public static int InstanceCount()
{
return this.instanceCount;
}
...
private static int instanceCount = 0;
}
There are some very important restrictions that apply to destructors:
Destructors apply only to reference types. You cannot declare a destructor in a value type, such as a struct.
struct Tally
{
~Tally() { ... } // compile-time error
}
You cannot specify an access modifier (such as public) for a destructor. You never call the destructor in your own code—part of the the runtime called the garbage collector
does this for you.
public ~Tally() { ... } // compile-time error
You never declare a destructor with parameters, and the destructor cannot take any parameters. Again, this is because you never call the destructor yourself.
~Tally(int parameter) { ... } // compile-time error
The compiler automatically translates a destructor into an override of the Object.Finalize method. The compiler translates the following destructor:
class Tally
{
~Tally() { ... }
}
260 |
Part II Understanding the C# Language |
|
into this: |
|
class Tally |
|
{ |
|
protected override void Finalize() |
|
{ |
|
try { ... } |
|
finally { base.Finalize(); } |
|
} |
|
} |
|
The compiler-generated Finalize method contains the destructor body inside a try block, |
|
followed by a finally block that calls the Finalize method in the base class. (The try and finally |
|
keywords are described in Chapter 6, “Managing Errors and Exceptions.”) This ensures that a |
|
destructor always calls its base class destructor. It’s important to realize that only the com- |
|
piler can make this translation. You can’t override Finalize yourself, and you can’t call Finalize |
|
yourself. |
Why Use the Garbage Collector?
You should now understand that you can never destroy an object yourself by using C# code. There just isn’t any syntax to do it, and there are good reasons why the designers of C# decided to forbid you from doing it. If it were your responsibility to destroy objects, sooner or later one of the following situations would arise:
You’d forget to destroy the object. This would mean that the object’s destructor (if it had one) would not be run, tidying up would not occur, and memory would not be deallocated back to the heap. You could quite easily run out of memory.
You’d try to destroy an active object. Remember, objects are accessed by reference. If a class held a reference to a destroyed object, it would be a dangling reference. The
dangling reference would end up referring either to unused memory or possibly to a completely different object in the same piece of memory. Either way, the outcome of using a dangling reference would be undefined at best or a security risk at worst. All bets would be off.
You’d try and destroy the same object more than once. This might or might not be disastrous, depending on the code in the destructor.
These problems are unacceptable in a language like C#, which places robustness and security high on its list of design goals. Instead, the garbage collector is responsible for destroying objects for you. The garbage collector makes the following guarantees:
Every object will be destroyed and its destructors run. When a program ends, all outstanding objects will be destroyed.
Every object will be destroyed exactly once.