Question about Class Destruction

  • Thread starter Thread starter Terrance
  • Start date Start date
T

Terrance

I've been using .net for a while now as novice user and I understand the
concept of the garbage collection to a degree. My question is simple and I'm
sure someone out there can help me. Is it good practice to destroy a class
when when it's no longer needed? for example if I have the following code
within a procedure:

myClass a = new myClass();

Try
{
Class work...
}
catch
{
}
finally
{
a = null;
}

Is it good practice to destroy the class? In my code I want to be efficient
as possible and I'm looking for real good practices. If this was a COM object
I'm assuming that it would be good to destroy the object because garbage
collection sees this as unsafe code. Correct or incorrect?
 
Terrance said:
I've been using .net for a while now as novice user and I understand the
concept of the garbage collection to a degree. My question is simple and I'm
sure someone out there can help me. Is it good practice to destroy a class
when when it's no longer needed?
Click to expand...

..NET has no concept of "destroying" an object (not a class -- keep these
things well separated!) What it has is automatic memory management and
finalization (which frees up anything that's not under the purview of the
CLR, i.e. resources that are not memory). When an object is garbage
collected, it will be queued for finalization if it needs to be finalized,
and afterwards its memory will be freed. Finalizers come closest to
destructors in terms of functionality (but not use).

The MSDN has an excellent if somewhat overwhelming overarching topic:
http://msdn2.microsoft.com/library/0xy59wtx

You should especially read the first two entries; the rest is advanced stuff
you won't encounter very often.
for example if I have the following code
within a procedure:

myClass a = new myClass();

Try
{
Class work...
}
catch
{
}
finally
{
a = null;
}

Is it good practice to destroy the class?
Click to expand...

Setting a reference to null does not "destroy" anything and it furthermore
has no effect on the ability of the CLR to collect objects that are no
longer referenced. (This is not entirely true, but when you understand why
it's not entirely true you won't need this advice anymore, so I'm skipping
the details.) In particular, it will not force the object to be collected
and it will not cause unmanaged resources to be released.

Code like this is especially popular among programmers that are migrating
from VB (since this was the accepted way of releasing COM objects), but it
should not be used in .NET. Instead, classes whose instances hold resources
that need to be freed in a deterministic manner should implement
IDisposable, and clients should take care to call Dispose() on objects they
no longer need. A useful shorthand for this is the using statement:

using (MyClass a = new MyClass()) {
...
}

which is roughly equivalent to:

MyClass a;
try {
a = new MyClass();
...
} finally {
if (a != null) a.Dispose();
}

See the documentation on IDisposable for more information, and "Implementing
Finalize and Dispose to Clean Up Unmanaged Resources"
(http://msdn2.microsoft.com/library/b1yfkh5e). Note that most classed do not
need finalization, do not need to implement IDisposable and in short do not
need to do anything special for garbage collection to "just work".
In my code I want to be efficient as possible and I'm looking for real
good practices. If this was a COM object I'm assuming that it would be
good to destroy the object because garbage collection sees this as unsafe
code. Correct or incorrect?
Click to expand...

Incorrect, and incidentally "unsafe code" is something completely different
(http://msdn2.microsoft.com/library/t2yzs44b), not to be confused with
"unmanaged resources".

It is true that the COM object will probably take up unmanaged resources,
and if you cannot wait for these to be disposed when the COM object is
released (which will happen when it's garbage collected) you can force a
release through the special method Marshal.ReleaseComObject(). This is
particular to COM objects, however, and does not apply in general.
 
I've been using .net for a while now as novice user and I understand the
concept of the garbage collection to a degree. My question is simple and I'm
sure someone out there can help me. Is it good practice to destroy a class
when when it's no longer needed? for example if I have the following code
within a procedure:

myClass a = new myClass();

Try
{
Class work...
}
catch
{
}
finally
{
a = null;
}

Is it good practice to destroy the class? In my code I want to be efficient
as possible and I'm looking for real good practices. If this was a COM object
I'm assuming that it would be good to destroy the object because garbage
collection sees this as unsafe code. Correct or incorrect?
Click to expand...

Your code does not destroy the instance of the class, it just removes
all references to it (assuming nothing in the Try block stores the
reference to the instance somewhere else) which makes it eligible for
garbage collection.

If the scope of 'a' is local to a method, and there is little
execution time from the point where you no longer need the instance to
the end of the method, then my understanding is that there is no need
to set the reference to null, and in some cases it might be
counter-productive.

If the scope of the variable holding the reference was for more than
just the current method, then I would clear the reference when it was
no longer needed, but I think such a case would be unusual.

Of course if the class has unmanaged resources, then you would want to
call the class's Dispose method, either explicitly or by putting it in
a 'using' block, as soon as you are finished with it.
 
Back
Top