Usually when you have a class that is responsible for handling dynamically created memory with new or new[]. Destructors enable an idiom known as "RAII" (stands for "Resource Acquisition Is Initialisation"... don't ask why its called that, its a terribly bad, misleading name) - Which is essentially a way to prevent classes from causing memory leaks.

For example, imagine a linked list class. The linked list class will be solely responsible for creating links. When the linked list object dies, you want it to automatically destroy all the links, rather than requiring the user to do that for you. The destructor will (hopefully) have a call that cleans up all of the new'ed memory, and prevent that class from causing memory leaks in the program.

Incidentally, one can never, and should never, call a destructor. A destructor is either invoked by a call to delete, delete[] on a dynamically created object (with new or new[])
or the destructor is invoked implicitly when an object goes "out of scope" (Or, for static objects, when the program ends..). You certainly should never have code which looks like my_object.~my_class(); (I believe that's a compiler error, but just in case its not, don't do it!).
For most classes, the default, empty destructor is enough. A destructor cannot be overloaded, nor can it take any arguments. Sometimes, when creating polymorphic base classes, you may wish to create an empty virtual destructor, to ensure that objects used polymorphically can be properly cleaned up



That's about all you need to do. A side note though, (You can stop reading here if you like..). There is a rule known as "the rule of 3" - whereby, if your class needs a destructor, then it probably needs a Copy Constructor and an overloaded Assignment Operator ( = ) too. The reason for this, is that dynamic memory "belonging" to the class does not get copied automatically when an instance of that class is copied.

What would happen if you had no copy constructor/assignment operator, when the object is copied, is that both objects would "point" to the same dynamically created objects.

Sometimes this behaviour is desirable, and is known as a "shallow" copy. More often though, a copy constructor/assignment operator will be used to duplicate all the data along with the copied object - That operation performs a "deep" copy.



In general, its best to leave dynamic memory alone until its really necessary. There's much that you can do with the STL which will allow you to design classes without worrying about new/delete.

__________________

---