Re: noob question - destructors - freeing memory...
On 12/31/2011 03:06 AM, MikeWhy wrote:
someone wrote:
Hi
See this (stolen from the internet):
----------------------------------------
#include <iostream>
using namespace std;
class Base
{
public:
Base(){ cout<<"Constructing Base"<<endl;}
// this is a destructor:
virtual ~Base(){ cout<<"Destroying Base"<<endl;}
};
class Derive: public Base
{
public:
Derive(){ cout<<"Constructing Derive"<<endl;}
~Derive(){ cout<<"Destroying Derive"<<endl;}
};
int main()
{
Base *basePtr = new Derive();
// delete basePtr; // <<<======== !! ! ! ! ! NB !!
return 0;
}
----------------------------------------
See middle line of main():
delete basePtr; // <<<======== !! ! ! ! ! NB !!
If I enable (uncomment) middle line, I get:
Constructing Base
Constructing Derive
Destroying Derive
Destroying Base
If I disable (comment out) middle line, I get:
Constructing Base
Constructing Derive
========
This, I didn't quite expect, because I thought that at the end of the
program, all destructors where guaranteed to be called...
If pointers had destructors, what action should they take?
Delete themselves? But not before they've destructed the objects they're
pointing to! After they've destructed (free'd) the dereferenced objects,
the pointers can free themselves...
Why doesn't that happen in the example in my post and in my full code?
In my case, I have a longer program and I allocate memory with one of
my constructors, hence it is crucial to free the memory, but since the
virtual destructor is never called, I never free the memory...
In addition: In my full program (not shown here), I instantiate my new
object like:
int main(...)
{
...
Derive d1();
return 0; // or exit(1); if something went wrong somewhere
}
Is it required that I do, like in the example above:
int main(...)
{
...
Base *myPtr = new Derive();
foo(); // insert this line. See below.
delete myPtr;
return 0; // or exit(1); if something went wrong somewhere
}
???????
Yes.
Ok, but I don't understand why... I found this post:
http://www.tech-archive.net/Archive/VC/microsoft.public.vc.mfc/2007-05/msg01433.html
from where I qoute: "Static objects are deleted (so the destructor is
called) when global variables are deallocated, so when the program exits."
I believe this code:
int main(...)
{
...
Derive d1();
return 0; // or exit(1); if something went wrong somewhere
}
Has d1 to be a static object, hence when the program exits, the
destructor of d1 should be called just before exitting... Why don't this
happen?
But what if my code does an exit(1) somewhere, which it could do at
least a dozens of times, in different parts of the program?
exit() is a function call. In your final example above, if foo() called
exit(1), will your destructor be called? Given what you saw earlier, how
does exit() trigger process termination?
exit() is not a normal function call. Normally, code execution continues
right after the function calls. But not with exit(). Code below exit()
is not executed.
If instead of calling exit(), foo() throws an uncaught exception. How
does the program behave?
I later found some posts on google, suggesting to throw/catch
exceptions, however I'm not very good at using exceptions and fear that
the code will be much more complicated.
Calling exit() is a very bad idea. Ditto for terminating threads, only
more so. A simple return will suffice. Find some other mechanism to
trigger process (and thread) termination.
return() has exactly the same problem as exit: The code below return()
in main is not executed, hence I believe that exit() is some kind of
acronym for return() (from the main thread)...
Anyway, please explain why the static destructor is not called on exit.
I don't understand why not...