Like the title suggests, for OOP, do I need to define a deconstructor all the time?
Or do I just not type it at all, will it have a default deconstructor, like the default constructor?
Like the title suggests, for OOP, do I need to define a deconstructor all the time?
Or do I just not type it at all, will it have a default deconstructor, like the default constructor?
A default one is provided, but there might be reasons why you'd need to make your own.
Your questions are good, but I think at this point, you'd be better off reading the tutorials and FAQs on this site and asking questions when you run into trouble.
http://www.cprogramming.com/tutorial.html
Only if it's needed:
Here memory is allocated, but it's not destroyed, so you need a destructor there:Code:class thing { private: char *t; public: thing( void ) { t = new char[100]; } }; int main( void ) { { // thing created thing kfsd; } // thing destroyed return 0; }
Like so. But if you don't allocate memory using new (or some C functions), you don't need to delete it afterwards, so you don't need a destructor.Code:class thing { private: char *t; public: thing( void ) { t = new char[100]; } ~thing( void ) { delete []t; } }; int main( void ) { { // thing created thing kfsd; } // thing destroyed return 0; }
Hey, thanks everyone
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 :/
Last edited by markcls; 03-25-2007 at 12:07 PM.
>> deconstructor
"destructor" not "deconstructor"
>> 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.
Or to put some code to Daved's words:
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.Code:class thing { private: char *t; public: thing( void ) { t = new char[100]; } ~thing( void ) { delete []t; } }; int main( void ) { thing *kjldsf = new thing[100]; // this NEEDS to be deleted. delete []kjldsf; return 0; }
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
This is not essential. I belive there will be a new operartor called NULLPtr or somthing with the new standard. Not 100% sure on this though.Code:foo::~foo() { delete myInt; myInt = NULL; }
Double Helix STL
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.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
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
>> 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.
I never heard of that before.
So, you could change the destructor I posted earlier to:
One question is commented. Should the t be within the scope of the if statement? Or does it matter?Code:~thing( void ) { if( t ) delete []t; //Should this be within the if? t = NULL; }
That's how you should do it, the rest is completely unnecessary clutter.Code:~thing( void ) { delete [] t; }
That's what I thought. Thought for a sec that I would have to rewrite some things.