good evening folks, I just have a quick question regaurding destructors.. is it always necessary to have one for your classes? or is it only necessary to have them when you allocate memory dynamically? also, when calling a destructor on a pointer, do you delete it first then set it to NULL? or the other way around? thanks for your help Aztec

No, you don't EVER really need to declare a class destructor in your application, but it is much better to do so. Doing so can let you do a lot more things than you regularily could! If you don't create a class destructor, the compiler provides a defualt destructor for you.

When you call a destructor on a pointer, you delete the pointer, THAN assign it to NULL. If you assign it to NULL before you delete it, it can sometimes cause confusion in your code (and sometimes even a little creepy bug). I was taught to delete, then assign to NULL, and I believe that this is the correct way, so JUST DO IT! j/k delete it, then assign the pointer to NULL.

Edited by - Fredric on 2/25/00 10:10:07 PM

ahh, thanks man.
I knew about the compiler making a default destructor, but wasn''t sure if it was necessary or just good programming practice to make your own destructor. at any rate, thank you for the help

Aztec

Another use would be if you had a class for monsters and then had a variable for the number of monsters on the screen you would increment it by 1 in the constructor and decrease it by 1 in the destructor then you would know when they were all killed.

I see lots of people that set member pointers to NULL after deleting them in the destructor of the owning class. And I always wonder, why? Who cares if the pointer is NULL? The destructor is running, which means the enclosing class is going to be vaporized momentarily.

-Brian

I think this is basically programming paranoia, osmanb. Happened to me too, once or twice. When there''s an irritating bug with memory usage and you can''t figure out where the problem is, you do anything to try to pinpoint it, including setting the pointer to NULL in case, after your destructor is called, the compiler-generated code sees the pointer isn''t NULL and tries to destroy it. That''s not what actually happens, but when you keep getting an error when you try to delete an object, and you can''t figure out what it is, you do things like that =)

~CGameProgrammer( );

Actually I had a really nasty bug in a garbage collection library I used as an undergrad. It did batch deallocations of memory (for only heaven knows what reason) and if the batch hadn''t been deallocated yet, the pointer looking like objects would still be considered valid references, if you didn''t set the pointer to NULL. So it counted the referenced memory as still referenced. This in turn meant that a linked list that wasn''t deallocated properly (i.e. pointers NULLed) would be actually be deallocated over the course of several batches. And because it did a stupid scan every time it ran low on memory, and the thing didn''t deallocate things properly, it spent forever in garbage collection.

In case your wondering the library was called RAGCL. I believe the grad student that wrote it dropped out. So hopefully you''ll never have to deal with it.

Aztec: The delete keyword calls the destructor of your class, then after the destructor has finished, delete deallocates the non-dynamic (i.e., non-pointer) data members. Setting the pointer to NULL is good programming practice, but it''s not necessary.

osmanb: If you try to build a complex class heirarchy, and you''ve got several (sometimes many) "layers" of destructors for your object, it''s helpful to know exactly where the pointer is deleted. Or, you could use it if the memory might be de-allocated in several different places in the class, and you''re not sure at run-time whether the memory will be gone by the time the destructor gets to the base class. Using the following code in the destructor gives you more flexibility in using the class:

if( m_pData != NULL )
{
delete m_pData;
m_pData = NULL;
}

I usually just put that in a macro called SAFE_DELETE() so that the code is cleaner. It''s always good coding practice to make sure all pointers are NULL when they don''t have valid data. Destructing objects isn''t normally time critical.

If you''ve ever tried to build a class library (with inheritance), you''d know what I mean about destructors

Good Luck!


- null_pointer