Destructors & exit(0)

Will the destructor for a class execute if I use the exit(0); at a random place in the program?

That's a bad idea to use exit() when you have classes.

i'm wondering if it's neccessary to call a function that deletes all the dynamic stuff before exiting(0)

I believe that exit() destroys static members, but does not call the destructors, so I would think you should do something to destroy all of the dynamic stuff before exit()

Thankee so much.

going further into this topic, if int main() ended by return or it reaches the end bracket, are destructors called then? or does the programmer need to call destructors manually all the time?

i think the destructors are called if the object wasn't declared as pointers and then new'ed.

if they were new'edpointers, then they'd have to be deleted.

i'm not 100% on this, though.

destructors are called when an instance of the class goes out of scope. (just like any other variable)

The Dog:
If your object creates dynamic instances of some other object, you would have your destructor do the 'deleting' of those created objects...

destructors are an automation, there's nothing tricky about them

Quote:

---

Will the destructor for a class execute if I use the exit(0); at a random place in the program?

---

Destructors are called whenever an object is destroyed, either explicitly (MyClass::~MyClass) or implicitly (move out of scope). The exit function will destroy all static (non-dynamic) variables and classes, calling the destructors as required. Return from main() is the same as exit. Using abort() will immediately exit the program without calling destructors.

Quote:

---

i think the destructors are called if the object wasn't declared as pointers and then new'ed. if they were new'edpointers, then they'd have to be deleted. i'm not 100% on this, though.

---

True. For dynamically created objects, the destructor will not be called unless the object is specifically deleted. If a pointer moves out of scope, the pointer itself is destroyed but not the object it points to. If your program exits without destroying objects on the heap, those objects will not be destroyed and the memory will not be returned to the system. It is lost; the OS will not reallocate that memory. More correctly, there is no guarantee that the memory will be returned to the OS. Most OS's are pretty good about cleaning up after a program, but you shouldn't depend on it.

fletch

While fletch is correct in saying that all static objects will be destructed. auto objects (normally those created on the stack - not with new) will not necessarily be destructed. Therefore if you've allocated within these objects you may have a memory leak.

I believe you will be better off avoiding exit() and finding a mechanism to allow your program to die naturally.

Quote:

---

While fletch is correct in saying that all static objects will be destructed. auto objects (normally those created on the stack - not with new) will not necessarily be destructed. Therefore if you've allocated within these objects you may have a memory leak.

---

Static objects are automatically deleted, but doesn't the compiler clean up the stack as part of exit()? Hmmm...wait...the keyword there is compiler - not something that you can always rely on. Hence "will not necessarily be destructed." Don't you love it when you answer your own question?

Quote:

---

I believe you will be better off avoiding exit() and finding a mechanism to allow your program to die naturally.

---

That is a fact.

fletch

hehe, well at least we have firmly agreed that static objects will be destroyed :)

thankyou all, that clears it up.