Must I always use a deconstructor?

This is a discussion on Must I always use a deconstructor? within the C++ Programming forums, part of the General Programming Boards category; Like the title suggests, for OOP, do I need to define a deconstructor all the time?
Or do I just ...

twomers: Hmm, so does that mean if I define a deconstructor to free whatever memory I've allocated for that object, I won't have to specifically free (delete) the object before the program ends? It'll be done automatically when I exit the program?

And thanks MacGyver for pointing me in the right direction

Edit: Oh and sorry for so many basic questions. I have an urgent job of translating Java to C++ and I don't have much time to search here and there :/

>> does that mean if I define a deconstructor to free whatever memory I've allocated for that object, I won't have to specifically free (delete) the object before the program ends? It'll be done automatically when I exit the program?

No. Any memory you allocate with new, you have to deallocate with delete. If you create an object locally (like kfsd in twomers code), then you don't have to do anything it will be destroyed on its own. Since it is a class, its destructor will be called automatically. However, if it has its own data that it allocated with new, you have to make sure that gets cleaned up in the class destructor.

Everything inside each of the elements will get deleted with the destructor, but since the pointer kjldsf (sorry for the bad name, I couldn't think of anything so I slammed my face on the keyboard), has memory dynamically allocated to it outside of the scope of the class this needs to be deleted outside of it, ie in main.

Also note that in modern C++ you don't use the destructor as often as you'd think. For example, you don't actually create arrays like in twomers example code, you use the vector class instead (or some other suitable container). The vector class cleans up after itself automatically (with its own destructor) and so you don't have to write a destructor for a class that uses it. The default destructor will call vector's destructor automatically and it will be cleaned up for you.

A bit more on that.
Whenever you need a destructor you also need to define a copy constructor and an assignement operator. If you want that the object is not copyable or assignable, make them private.
The default implementations that the compiler generates will get you in trouble.
Like in the examples from twomers. The destructor of a copy would delete t as well resulting in double delete of the same memory.
Kurt

Just to point out, if you allocate memory with new in the constructor then delete it with the destructor, to be safe NULL the pointer to be absolutley sure the memory is deleted

I had the impression is that the delete/delete[] was the one that results in deallocation of memory, and zeroing the pointer is just to be safe, as a second delete/delete[] would then be effectively a no-op, plus you can check to see if the pointer is null if you want to be certain before dereferencing it.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

>> to be safe NULL the pointer to be absolutley sure the memory is deleted.
There is really no reason to do this in a destructor. Apparently some extremely old compilers had a bug where not doing so would cause a crash, but if your compiler has that bug you should change compilers rather than worry about it.