Is There A Deconstructor For A C# Class Like In Visual C++?

[2MuchRiceMakesMeSick]

Is There A Deconstructor For A C# Class Like In Visual C++?

[jmcilhinney]

I believe you can create destructors a la C/C++ but you normally wouldn't. Look into implementing the Dispose and Finalize methods, which is the standard method of object cleanup in .NET.

[2MuchRiceMakesMeSick]

I assume C# automatically cleans up and deletes the variables?

[jmcilhinney]

Stack variables are no issue. It's objects on the heap and particularly unmanaged resources that you need to be concerned with.

http://msdn.microsoft.com/library/de...poseMethod.asp
http://msdn.microsoft.com/library/de...izeDispose.asp

[x-ice]

I assume C# automatically cleans up and deletes the variables?

You should be able to invoke the Garbage Collector if you feel it is necessary at some point. Not quite sure how though.

In Java its System.gc()

[usamaalam]

What about implementing a ~User() method, where User is the class name.

You can invoke garbage collector using GC.Collect();.

[jmcilhinney]

It should be a very rare thing that anyone needs to force garbage collection. Avoid calling GC.Collect unless you have a good reason.

~User() is an example of a destructor, which was the original question. C# supports destructors but the .NET convention is to use Dispose and Finalize methods. The help says that a destructor is implicitly converted to a Finalize method anyway. The advantage of using Dispose is that it can be called explicitly, while destructors and Finalize methods are only called when the GC decides to clean up the object.

If you do a help search for "destructors" you'll get a fair amount of information, including the advice to avoid forcing garbage collection.

[2MuchRiceMakesMeSick]

Ill try to explain what im doing a little better.

Let say I declare a class under the namespace so it’s accessible globally throughout the form.

CTestClass cls = new CTestClass();

When Im done with the class I dont need it anymore.
How do I get rid of it?

[jmcilhinney]

This is basically how garbage collection works in .NET. Whenever there are no references remaining to an object on the heap, that object is tagged as available for garbage collection. This means that the object sits around in memory until the garbage collector decides it needs the space, at which point the object's Finalize method is called and it is cleaned up and the resources it held are reclaimed. Now let's say that that object was a String. The only resources that that object held was the space it occupied in memory, so there is no need for it to have a Dispose method because there is nothing for it to do. If, however, that object was a Form then it would be holding other resources, like handles and the like. If that Form's Dispose method was not called before the last reference to it lost scope then those resources would be unavailable to the system until the garbage collector decided to clean it up. That's why some classes have Dispose methods and others don't. If your class holds any unmanaged resources itself then it really should implement a Dispose method to release these resources. The more usual situation is that your class would have variables that refer to other objects that have Dispose methods. In this case you should implement a Dispose method to call those Dispose methods. This will cause a cascade effect so that no matter how deep the unmanaged resources are, they will be released by the object that holds them because its Dispose method will have been called. If you don't, those resources will be tied up unnecessarily until the garbage collector decides it needs the memory occupied by your object.

In short, if your class has variables of a type that have a Dispose method, you should also implement a Dispose method to call them. When you have finished with your or any other object, if it has a Dispose method then call it. If the variable that refers to the object loses scope very soon then that's all you have to do. If the variable doesn't or might not lose scope for some time then set the varaible to null. That removes the reference to the object and thus it becomes eligible for garbage collection.

[Rattlerr]

This is out of my Visual C# 2005 Book from Microsoft:

class Tally
{
public Tally()
{
this.instanceCount++;
}
~Tally()
{
this.instanceCount--;
}
public static int InstanceCount()
{
return this.instanceCount;
}
private static int instanceCount = 0;
}

You can Not declare a destructor in a Struct.A struct is a value type that lives on the stack and not the heap, so garbage collection does not apply..

struct Tally
{
~Tally() {...} // compile - time error
}
You cannot declare an access modifier (such as public) for a destructor.This is because you never call a destructor yourself - the garbage collector does.

public ~Tally() {...}// compile - time error

You never declare a destructor with parameters, and it cannot take any parameters AGain, this is because you never call a 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() {...}
}
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 base class Finalize.This ensures that a destructor always calls its base class destructor.It's important to realize that only the compiler can make this translation.You can not override Finalize yourself and you cant call Finalize yourself..

[jmcilhinney]

Bugger! I've had my help filter on VB and as a result I've been posting (almost) complete rubbish. In VB you DO override the Finalize method yourself, whereas in C# you write a destructor and this is implicitly converted to an overridden Finalize method, as Rattlerr's post points out. I've only ever done this myself in VB. That's what happens when your experience with a subject is all theoretical and not practical, and when you're too quick to believe your own opinion. My apologies for the bum steer.

[penagate]

yes, so there's not actually any such thing as a C++ style deconstructor in C#.