Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #12887 > unrolled thread

noob question - destructors - freeing memory...

Back to article view | Back to comp.lang.c++

Contents

  noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2011-12-31 02:43 +0100
    Re: noob question - destructors - freeing memory... "MikeWhy" <boat042-nospam@yahoo.com> - 2011-12-30 20:06 -0600
      Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2011-12-31 03:33 +0100
        Re: noob question - destructors - freeing memory... "MikeWhy" <boat042-nospam@yahoo.com> - 2011-12-30 21:22 -0600
          Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2011-12-31 04:57 +0100
            Re: noob question - destructors - freeing memory... "MikeWhy" <boat042-nospam@yahoo.com> - 2011-12-30 22:28 -0600
              Re: noob question - destructors - freeing memory... "MikeWhy" <boat042-nospam@yahoo.com> - 2011-12-30 22:43 -0600
              Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2011-12-31 05:49 +0100
                Re: noob question - destructors - freeing memory... "MikeWhy" <boat042-nospam@yahoo.com> - 2011-12-30 23:56 -0600
                  Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2011-12-31 07:07 +0100
                    Re: noob question - destructors - freeing memory... Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-31 01:50 -0800
                      Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2011-12-31 18:13 +0100
                        Re: noob question - destructors - freeing memory... Nobody <nobody@nowhere.com> - 2012-01-01 08:37 +0000
                        Re: noob question - destructors - freeing memory... LR <lruss@superlink.net> - 2012-01-01 10:54 -0500
                          Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2012-01-02 00:33 +0100
                            Re: noob question - destructors - freeing memory... "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-01 19:20 -0600
                              Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2012-01-02 03:55 +0100
                                Re: noob question - destructors - freeing memory... Stefan Ensslen <stefan@zollsoft.de> - 2012-01-02 04:32 -0800
                                  Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2012-01-02 17:40 +0100
                                    Re: noob question - destructors - freeing memory... Dombo <dombo@disposable.invalid> - 2012-01-02 19:14 +0100
                                      Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2012-01-02 21:30 +0100
                                  Re: noob question - destructors - freeing memory... jgk@panix.com (Joe keane) - 2012-01-07 23:23 +0000
                                    Re: noob question - destructors - freeing memory... "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-07 17:43 -0600
                            Re: noob question - destructors - freeing memory... Garrett Hartshaw <ghartshaw@gmail.com> - 2012-01-01 22:54 -0500
                              Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2012-01-02 05:29 +0100
                        Re: noob question - destructors - freeing memory... Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-01 13:38 -0800
                          Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2012-01-02 00:35 +0100
        Re: noob question - destructors - freeing memory... "Bo Persson" <bop@gmb.dk> - 2011-12-31 12:55 +0100
    Re: noob question - destructors - freeing memory... Garrett Hartshaw <ghartshaw@gmail.com> - 2011-12-30 22:50 -0500
      Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2011-12-31 05:37 +0100
        Re: noob question - destructors - freeing memory... LR <lruss@superlink.net> - 2011-12-31 01:07 -0500
          Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2011-12-31 08:54 +0100
            Re: noob question - destructors - freeing memory... Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-31 02:05 -0800
              Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2011-12-31 18:22 +0100
                Re: noob question - destructors - freeing memory... Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-01 13:45 -0800
                  Re: noob question - destructors - freeing memory... Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-02 12:17 +0000
                    Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2012-01-02 17:48 +0100
                      Re: noob question - destructors - freeing memory... Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-02 20:02 +0000
                Re: noob question - destructors - freeing memory... Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-01 13:42 -0800
        Re: noob question - destructors - freeing memory... Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-31 01:52 -0800
          Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2011-12-31 18:23 +0100
        Re: noob question - destructors - freeing memory... Garrett Hartshaw <ghartshaw@gmail.com> - 2011-12-31 12:35 -0500
          Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2012-01-02 00:47 +0100
    Re: noob question - destructors - freeing memory... Juha Nieminen <nospam@thanks.invalid> - 2011-12-31 09:40 +0000
      Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2011-12-31 18:26 +0100
        Re: noob question - destructors - freeing memory... Garrett Hartshaw <ghartshaw@gmail.com> - 2011-12-31 13:00 -0500
        Re: noob question - destructors - freeing memory... Nobody <nobody@nowhere.com> - 2012-01-01 08:57 +0000
          Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2012-01-02 00:43 +0100
        Re: noob question - destructors - freeing memory... Juha Nieminen <nospam@thanks.invalid> - 2012-01-01 09:03 +0000
          Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2012-01-02 00:49 +0100
            Re: noob question - destructors - freeing memory... LR <lruss@superlink.net> - 2012-01-01 21:11 -0500
              Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? someone <newsboost@gmail.com> - 2012-01-02 05:23 +0100
                Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION
 FOUND? Garrett Hartshaw <ghartshaw@gmail.com> - 2012-01-02 00:14 -0500
                  Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? someone <newsboost@gmail.com> - 2012-01-02 17:55 +0100
                  Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? someone <newsboost@gmail.com> - 2012-01-02 22:17 +0100
                    Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION
 FOUND? Garrett Hartshaw <ghartshaw@gmail.com> - 2012-01-02 16:40 -0500
                      Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? someone <newsboost@gmail.com> - 2012-01-03 00:48 +0100
                Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? LR <lruss@superlink.net> - 2012-01-02 14:47 -0500
                  Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? someone <newsboost@gmail.com> - 2012-01-03 00:43 +0100
                    Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? LR <lruss@superlink.net> - 2012-01-02 20:30 -0500
                      Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? someone <newsboost@gmail.com> - 2012-01-03 19:08 +0100
                        Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? LR <lruss@superlink.net> - 2012-01-03 17:46 -0500
                          Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? someone <newsboost@gmail.com> - 2012-01-04 21:11 +0100
                            Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? LR <lruss@superlink.net> - 2012-01-04 18:56 -0500
                        Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION
 FOUND? Garrett Hartshaw <ghartshaw@gmail.com> - 2012-01-03 19:49 -0500
                          Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? LR <lruss@superlink.net> - 2012-01-03 21:51 -0500
                            Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION
 FOUND? Garrett Hartshaw <ghartshaw@gmail.com> - 2012-01-03 23:37 -0500
                              Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? LR <lruss@superlink.net> - 2012-01-04 14:24 -0500
                                Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? someone <newsboost@gmail.com> - 2012-01-04 21:20 +0100
                                  Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? LR <lruss@superlink.net> - 2012-01-04 18:51 -0500
                                    Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? someone <newsboost@gmail.com> - 2012-01-05 07:32 +0100
            Re: noob question - destructors - freeing memory... Garrett Hartshaw <ghartshaw@gmail.com> - 2012-01-01 23:02 -0500
              Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2012-01-02 05:33 +0100
              Re: noob question - destructors - freeing memory... "io_x" <a@b.c.invalid> - 2012-01-02 11:05 +0100
            Re: noob question - destructors - freeing memory... Juha Nieminen <nospam@thanks.invalid> - 2012-01-02 06:22 +0000
              Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2012-01-02 18:03 +0100
    Re: noob question - destructors - freeing memory... "Bo Persson" <bop@gmb.dk> - 2011-12-31 12:51 +0100
      Re: noob question - destructors - freeing memory... someone <newsboost@gmail.com> - 2011-12-31 18:18 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#12887 — noob question - destructors - freeing memory...

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...

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();
   delete myPtr;
   return 0; // or exit(1); if something went wrong somewhere
}

???????

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?


Please advice, thank you!

[toc] | [next] | [standalone]

#12888

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?

> 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.

>
> 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?

If instead of calling exit(), foo() throws an uncaught exception. How does 
the program behave?

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.

[toc] | [prev] | [next] | [standalone]

#12889

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...

[toc] | [prev] | [next] | [standalone]

#12890

someone wrote:
> 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)...

return is a C/C++ keyword. exit() is a function call. It kills the process 
and does not return. Since exit() doesn't return, foo() doesn't return. 
Since foo() doesn't return, execution will not continue in main(). Your 
delete will not be called.

You're asking the right questions. You now need to understand the 
distinction.

There also was a reason to bring up exceptions. The exception would have 
behaved as you thought exit() might. In the contexts you describe -- calling 
exit(1) in multiple locations -- the semantics and behavior are as you 
expected from exit().


> Anyway, please explain why the static destructor is not called on
> exit. I don't understand why not...

The truth of the matter is that pointers do not have destructors. My 
intention was not to lead you astray, however. You'll visit this again in 
shared_ptr and auto_ptr classes.

[toc] | [prev] | [next] | [standalone]

#12893

On 12/31/2011 04:22 AM, MikeWhy wrote:
> someone wrote:
>> On 12/31/2011 03:06 AM, MikeWhy wrote:
>>> someone wrote:
..

>>>> 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?

No answer?

>>>> 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)...
>
> return is a C/C++ keyword. exit() is a function call. It kills the
> process and does not return. Since exit() doesn't return, foo() doesn't
> return. Since foo() doesn't return, execution will not continue in
> main(). Your delete will not be called.

But it's not the answer to why, when I create static objects, the 
destructor of d1 is not called when exitting... Right?

> You're asking the right questions. You now need to understand the
> distinction.
>
> There also was a reason to bring up exceptions. The exception would have
> behaved as you thought exit() might. In the contexts you describe --
> calling exit(1) in multiple locations -- the semantics and behavior are
> as you expected from exit().
>
>
>> Anyway, please explain why the static destructor is not called on
>> exit. I don't understand why not...
>
> The truth of the matter is that pointers do not have destructors. My
> intention was not to lead you astray, however. You'll visit this again
> in shared_ptr and auto_ptr classes.

So you don't want to explain it?

FYI: I have no shared_ptr and auto_ptr classes, I don't know what it 
means and I'll never take them. I'm too old for that. You're not that 
old yourself and hence assumed that everyone in here is a student, doing 
school work? Never heard of something like: Went out of school years 
ago, but am learning a new programming language anyway?

I don't understand why you not just explain it, instead of all this 
irrelevant talk about if pointers have destructors and "you'll learn 
that when you've taking the same courses in school like myself, son"?

The exception throw/catch-talk however, was relevant, thank you for that.

I don't see many explations to the static destructor-thing yet...

[toc] | [prev] | [next] | [standalone]

#12894

someone wrote:
> On 12/31/2011 04:22 AM, MikeWhy wrote:
>> someone wrote:
>>> On 12/31/2011 03:06 AM, MikeWhy wrote:
>>>> someone wrote:
> ..
>
>>>>> 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?
>
> No answer?

Answered below in that message.

>
>>>>> 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)...
>>
>> return is a C/C++ keyword. exit() is a function call. It kills the
>> process and does not return. Since exit() doesn't return, foo()
>> doesn't return. Since foo() doesn't return, execution will not
>> continue in main(). Your delete will not be called.
>
> But it's not the answer to why, when I create static objects, the
> destructor of d1 is not called when exitting... Right?
>
>> You're asking the right questions. You now need to understand the
>> distinction.
>>
>> There also was a reason to bring up exceptions. The exception would
>> have behaved as you thought exit() might. In the contexts you
>> describe -- calling exit(1) in multiple locations -- the semantics
>> and behavior are as you expected from exit().
>>
>>
>>> Anyway, please explain why the static destructor is not called on
>>> exit. I don't understand why not...
>>
>> The truth of the matter is that pointers do not have destructors. My
>> intention was not to lead you astray, however. You'll visit this
>> again in shared_ptr and auto_ptr classes.
>
> So you don't want to explain it?

I'll go so far as to say that pointers -- along with int, char, and arrays 
as further examples -- do not have destructors. Plain old data, POD, as 
opposed to classes and structs. To say more would needlessly repeat 
countless books, articles, blogs, and archived usenet and chatboard 
postings. From your well reasoned earlier post, it did seem to me all you 
needed was a well directed nudge.

To answer your question, then... What would happen in your first example, 
where you passed an int* to a function, if pointers had the behavior of 
deleting their pointee in their hypothetical destructor?

I am still of the opinion that you need only a nudge, not a silver spoon. If 
that wasn't the case, I assure you I would not be spending my time.


> FYI: I have no shared_ptr and auto_ptr classes, I don't know what it
> means and I'll never take them. I'm too old for that. You're not that
> old yourself and hence assumed that everyone in here is a student,
> doing school work? Never heard of something like: Went out of school
> years ago, but am learning a new programming language anyway?
>
> I don't understand why you not just explain it, instead of all this
> irrelevant talk about if pointers have destructors and "you'll learn
> that when you've taking the same courses in school like myself, son"?
>
> The exception throw/catch-talk however, was relevant, thank you for
> that.
> I don't see many explations to the static destructor-thing yet...

It would please me if the explanation came next from you. It's entirely 
likely, or at least possible, that I've been out of school as long as you.

[toc] | [prev] | [next] | [standalone]

#12896

MikeWhy wrote:
> someone wrote:
>> FYI: I have no shared_ptr and auto_ptr classes, I don't know what it
>> means and I'll never take them. I'm too old for that. You're not that
>> old yourself and hence assumed that everyone in here is a student,
>> doing school work? Never heard of something like: Went out of school
>> years ago, but am learning a new programming language anyway?


Hmmm...

#include <memory>

You may discount my earlier post. I had not understood our communications to 
have been so severely crossed.

[toc] | [prev] | [next] | [standalone]

#12897

On 12/31/2011 05:28 AM, MikeWhy wrote:
> someone wrote:
>> FYI: I have no shared_ptr and auto_ptr classes, I don't know what it

Are these shared_ptr and auto_ptr relevant for solving the problem? I 
googled it, but not sure if they solve anything...

>> means and I'll never take them. I'm too old for that. You're not that
>> old yourself and hence assumed that everyone in here is a student,
>> doing school work? Never heard of something like: Went out of school
>> years ago, but am learning a new programming language anyway?
>>
>> I don't understand why you not just explain it, instead of all this
>> irrelevant talk about if pointers have destructors and "you'll learn
>> that when you've taking the same courses in school like myself, son"?
>>
>> The exception throw/catch-talk however, was relevant, thank you for
>> that.
>> I don't see many explations to the static destructor-thing yet...
>
> It would please me if the explanation came next from you. It's entirely
> likely, or at least possible, that I've been out of school as long as you.

Ok, good. Thank you very much.

I made a mistake, that confused me - I thought that the static 
destructor wasn't called, when main() returned with a 0... It confused 
me, don't know where I got that from...

Everything is ok, I asked some questions to Garret about how to fix my 
problem now, hopefully without using boost::shared_ptr, 
boost::scoped_ptr, etc.

hmmmmmmmmmmmmmmmmmm. Maybe a quick solution is to #define a macro 
exit(num), that does try and catch everytime I risk the program 
otherwise would be calling exit(1) etc... hmmmmmmmmmmmmm....

[toc] | [prev] | [next] | [standalone]

#12898

someone wrote:
> On 12/31/2011 05:28 AM, MikeWhy wrote:
>> someone wrote:
>>> FYI: I have no shared_ptr and auto_ptr classes, I don't know what it
>
> Are these shared_ptr and auto_ptr relevant for solving the problem? I
> googled it, but not sure if they solve anything...

They don't directly address your problem. Strictly speaking, I felt the 
problem was not simply that delete was not being called. The problem 
entirely was that execution did not flow as you expected. auto_ptr was 
relevant because it makes real that hypothetical deletion behavior 
mentioned.

>
> hmmmmmmmmmmmmmmmmmm. Maybe a quick solution is to #define a macro
> exit(num), that does try and catch everytime I risk the program
> otherwise would be calling exit(1) etc... hmmmmmmmmmmmmm....

It might be a good way to finish out your test program, which I understand 
to be a study of object lifetimes and program flow. I would not have chosen 
to introduce auto_ptr so early, but as it turns out, the role it plays is an 
important part of the broader topic of exception-safety.

As a final note, hiding throw in a macro for exit is a bad idea. Blindly 
replacing exit(1) with throw(1) might not be altogether unreasonable, 
though.

[toc] | [prev] | [next] | [standalone]

#12899

On 12/31/2011 06:56 AM, MikeWhy wrote:
> someone wrote:
>> On 12/31/2011 05:28 AM, MikeWhy wrote:
>>> someone wrote:

>> hmmmmmmmmmmmmmmmmmm. Maybe a quick solution is to #define a macro
>> exit(num), that does try and catch everytime I risk the program
>> otherwise would be calling exit(1) etc... hmmmmmmmmmmmmm....
>
> It might be a good way to finish out your test program, which I
> understand to be a study of object lifetimes and program flow. I would

The test program is finished. It's posted here in the thread. The other 
program is a big complicated program, where I have to find a solution, 
to the problem where the destructor is not called, when exit(1) and/or 
exceptions are thrown...

> not have chosen to introduce auto_ptr so early, but as it turns out, the
> role it plays is an important part of the broader topic of
> exception-safety.
>
> As a final note, hiding throw in a macro for exit is a bad idea. Blindly
> replacing exit(1) with throw(1) might not be altogether unreasonable,
> though.

Still don't solve the cleanup ("delete" / "free"ing up used memory 
space) problem... Not sure what to do then...

[toc] | [prev] | [next] | [standalone]

#12903

On Dec 31, 6:07 am, someone <newsbo...@gmail.com> wrote:
> On 12/31/2011 06:56 AM, MikeWhy wrote:
> > someone wrote:


> >> hmmmmmmmmmmmmmmmmmm. Maybe a quick solution is to #define a macro
> >> exit(num), that does try and catch everytime I risk the program
> >> otherwise would be calling exit(1) etc... hmmmmmmmmmmmmm....

not sure exactlywhat you're up to here. But

   - hiding standard libraries behind macros seems like a bad idea.
For a start it makes reading your code very difficult for other
people.

   - what do you mean "a macro [...] that catches everything"?
(slightly paraphrashing you)

As the other poster said calling exit() in a C++ is generally a bad
idea. It certainly precludes destrutors being called. I think the
effect you want could be had by throwing and not catching. This will
bubble all the way upto the top of the program, calling all the
relevent DTORs on the way. Then exiting.

> > It might be a good way to finish out your test program, which I
> > understand to be a study of object lifetimes and program flow. I would
>
> The test program is finished. It's posted here in the thread. The other
> program is a big complicated program, where I have to find a solution,
> to the problem where the destructor is not called, when exit(1) and/or
> exceptions are thrown...

there's something seriuslywrong if they aren't being called when
exceptions are thown!

> > not have chosen to introduce auto_ptr so early, but as it turns out, the
> > role it plays is an important part of the broader topic of
> > exception-safety.
>
> > As a final note, hiding throw in a macro for exit is a bad idea. Blindly
> > replacing exit(1) with throw(1) might not be altogether unreasonable,
> > though.
>
> Still don't solve the cleanup ("delete" / "free"ing up used memory
> space) problem... Not sure what to do then...

post a simple, working program that illustrates your problem.

[toc] | [prev] | [next] | [standalone]

#12919

On 12/31/2011 10:50 AM, Nick Keighley wrote:
> On Dec 31, 6:07 am, someone<newsbo...@gmail.com>  wrote:
>> On 12/31/2011 06:56 AM, MikeWhy wrote:
>>> someone wrote:
>
>
>>>> hmmmmmmmmmmmmmmmmmm. Maybe a quick solution is to #define a macro
>>>> exit(num), that does try and catch everytime I risk the program
>>>> otherwise would be calling exit(1) etc... hmmmmmmmmmmmmm....
>
> not sure exactlywhat you're up to here. But
>
>     - hiding standard libraries behind macros seems like a bad idea.
> For a start it makes reading your code very difficult for other
> people.

Ok, you're right... It was just a quick idea, so I didn't have to change 
too much... It's/was a bad idea, I can see that now...

>     - what do you mean "a macro [...] that catches everything"?
> (slightly paraphrashing you)

I mean, I have to "catch" whatever causes the program to quit and just 
before it would otherwise quit, it has to cleanup and THEN quit (not 
before having cleaned up).

> As the other poster said calling exit() in a C++ is generally a bad
> idea. It certainly precludes destrutors being called. I think the
> effect you want could be had by throwing and not catching. This will
> bubble all the way upto the top of the program, calling all the
> relevent DTORs on the way. Then exiting.

I've googled a bit around... It's completely stupid: I use opengl / GLUT 
and it seems, that if someone closes the glut-window, glut will call 
exit(0), exit(1) or whatever... I read that freeGLUT however, doesn't 
have this behaviour... It's ridiculous, isn't it?

With exit(0) from glut, is there any solution to cleaning up and freeing 
memory?

>>> It might be a good way to finish out your test program, which I
>>> understand to be a study of object lifetimes and program flow. I would
>>
>> The test program is finished. It's posted here in the thread. The other
>> program is a big complicated program, where I have to find a solution,
>> to the problem where the destructor is not called, when exit(1) and/or
>> exceptions are thrown...
>
> there's something seriuslywrong if they aren't being called when
> exceptions are thown!

Even if I figure out how to use exceptions: I think glut is not 
"cleanup"-friendly... I can't believe that...

And the OS is not freeing the memory when exit(0) or exit(1) is called?

OS = linux, windows or mac...

>>> not have chosen to introduce auto_ptr so early, but as it turns out, the
>>> role it plays is an important part of the broader topic of
>>> exception-safety.
>>
>>> As a final note, hiding throw in a macro for exit is a bad idea. Blindly
>>> replacing exit(1) with throw(1) might not be altogether unreasonable,
>>> though.
>>
>> Still don't solve the cleanup ("delete" / "free"ing up used memory
>> space) problem... Not sure what to do then...
>
> post a simple, working program that illustrates your problem.

I'm not fully convinced that exceptions are the solution, so I cannot 
show a simple working program yet.

What if the user pushes the "X" to close the glut-window and glut calls 
exit() ? I know glut is not the scope of this group, but I hope someone 
can clarify, because I'm not completely sure what to do now...

[toc] | [prev] | [next] | [standalone]

#12936

On Sat, 31 Dec 2011 18:13:49 +0100, someone wrote:

> I've googled a bit around... It's completely stupid: I use opengl / GLUT 
> and it seems, that if someone closes the glut-window, glut will call 
> exit(0), exit(1) or whatever... I read that freeGLUT however, doesn't 
> have this behaviour... It's ridiculous, isn't it?
> 
> With exit(0) from glut, is there any solution to cleaning up and freeing 
> memory?

The only thing I can think of is: call setjmp() in the main() function,
register an exit handler with atexit(), have the exit() handler longjmp()
back to main(), which just returns.

You can't just have the exit handler raise an exception because the exit
handler must have C linkage.

Also: note that exit() will invoke destructors of static objects, but not
those of automatic objects.

> And the OS is not freeing the memory when exit(0) or exit(1) is called?

The OS will reclaim all resources used by the process upon termination.
Memory will be reclaimed, files closed, locks released, etc. However, any
user-space clean-up (e.g. flushing buffers, writing an epilogue to an
output file, deleting temporary files, etc) must be done by the
application.

[toc] | [prev] | [next] | [standalone]

#12941

someone wrote:

> I've googled a bit around... It's completely stupid: I use opengl / GLUT 
> and it seems, that if someone closes the glut-window, glut will call 
> exit(0), exit(1) or whatever... I read that freeGLUT however, doesn't 
> have this behaviour... It's ridiculous, isn't it?

Can you use freeGLUT?
> 
> With exit(0) from glut, is there any solution to cleaning up and freeing 
> memory?

Doesn't glut offer callbacks that allow you to capture information about
mouse and keyboard events?  If so, you can use one of those to hook to
code that will call your destructors.  You may have to expose your data
to a global pointer or something to do that though.


> Even if I figure out how to use exceptions: I think glut is not 
> "cleanup"-friendly... I can't believe that...
> 
> And the OS is not freeing the memory when exit(0) or exit(1) is called?
> 
> OS = linux, windows or mac...

It might.  Or your development environment might if you're building a
debug version, but I wouldn't count on it. And since you're worried
about performance, maybe that's not the way to go.

> What if the user pushes the "X" to close the glut-window and glut calls 
> exit() ? I know glut is not the scope of this group, but I hope someone 
> can clarify, because I'm not completely sure what to do now...

Depends on if it can be captured per above.

Maybe glut isn't really the solution for you. There are a variety of
cross platform GUI toolkits for crossplatform apps. For example, I'm
pretty sure both wxWidgets and Qt have support for opengl and it's
possible both are available for the platforms you want to use.  Best to
check that and licensing before you start.

Searching around on the web might be useful too.  Maybe this would be of
interest? http://www.stetten.com/george/glutmaster/glutmaster.html  I
found that link here: http://www.opengl.org/resources/libraries/glut/faq/

[toc] | [prev] | [next] | [standalone]

#12955

On 01/01/2012 04:54 PM, LR wrote:
> someone wrote:
>
>> I've googled a bit around... It's completely stupid: I use opengl / GLUT
>> and it seems, that if someone closes the glut-window, glut will call
>> exit(0), exit(1) or whatever... I read that freeGLUT however, doesn't
>> have this behaviour... It's ridiculous, isn't it?
>
> Can you use freeGLUT?

Maybe... Just think it's strange that no good/easy solutions exists, if 
I understand this correctly...

>> With exit(0) from glut, is there any solution to cleaning up and freeing
>> memory?
>
> Doesn't glut offer callbacks that allow you to capture information about
> mouse and keyboard events?  If so, you can use one of those to hook to
> code that will call your destructors.  You may have to expose your data
> to a global pointer or something to do that though.

I tried to do something like that.
Keyboard events: Yes, no problem.
Clicking "X" window: I think the OS forces a kill without being able to 
capture anything...

>> Even if I figure out how to use exceptions: I think glut is not
>> "cleanup"-friendly... I can't believe that...
>>
>> And the OS is not freeing the memory when exit(0) or exit(1) is called?
>>
>> OS = linux, windows or mac...
>
> It might.  Or your development environment might if you're building a
> debug version, but I wouldn't count on it. And since you're worried
> about performance, maybe that's not the way to go.

So, like me you don't know if linux, windows or mac OS free's the memory 
when exit(0) or exit(1) is called, and at least we don't count on it 
unless somebody (in here?) says otherwise...

>> What if the user pushes the "X" to close the glut-window and glut calls
>> exit() ? I know glut is not the scope of this group, but I hope someone
>> can clarify, because I'm not completely sure what to do now...
>
> Depends on if it can be captured per above.
>
> Maybe glut isn't really the solution for you. There are a variety of
> cross platform GUI toolkits for crossplatform apps. For example, I'm
> pretty sure both wxWidgets and Qt have support for opengl and it's
> possible both are available for the platforms you want to use.  Best to
> check that and licensing before you start.

Hmm. Ok.

> Searching around on the web might be useful too.  Maybe this would be of
> interest? http://www.stetten.com/george/glutmaster/glutmaster.html  I
> found that link here: http://www.opengl.org/resources/libraries/glut/faq/

Hmm. Maybe yes. Although I didn't for sure read that this would be much 
better - it just says it's a C++ wrapper, but not much else...

[toc] | [prev] | [next] | [standalone]

#12961

"someone" <newsboost@gmail.com> wrote in message 
news:4f00ed4d$0$293$14726298@news.sunsite.dk...
> So, like me you don't know if linux, windows or mac OS free's the memory 
> when exit(0) or exit(1) is called, and at least we don't count on it 
> unless somebody (in here?) says otherwise...

Yes, we know for certain that Mac, Windows, and Linux/UNIX all release 
memory held by the process when they terminate. They also release mutexes, 
close files, sockets, and such. What isn't clear is whether your app leaves 
the files and shared resources in a consistent state when you slam the 
process. Device drivers and video libraries were once particularly fragile, 
but that is mostly just a bad rememberance these days.

It can be that for some or even many apps, process cleanup by the OS is 
sufficient. This should be a conscious choice, though, knowing what is safe 
and what is not, rather than left to chance out of ignorance. Destructors 
can do much more than simply release memory.

The largest problem in self-education is what you don't know about what you 
need to know. It looks like you're coming to grips with process flow on 
termination. You need to now understand more about what the OS thinks of a 
process, its resources and lifetime. It's a long path, and aside from my 
passing mention of destructors above, not language specific and probably 
should be moved to a different newsgroup.

[toc] | [prev] | [next] | [standalone]

#12963

On 01/02/2012 02:20 AM, MikeWhy wrote:
> "someone" <newsboost@gmail.com> wrote in message
> news:4f00ed4d$0$293$14726298@news.sunsite.dk...
>> So, like me you don't know if linux, windows or mac OS free's the
>> memory when exit(0) or exit(1) is called, and at least we don't count
>> on it unless somebody (in here?) says otherwise...
>
> Yes, we know for certain that Mac, Windows, and Linux/UNIX all release
> memory held by the process when they terminate. They also release
> mutexes, close files, sockets, and such. What isn't clear is whether
> your app leaves the files and shared resources in a consistent state
> when you slam the process. Device drivers and video libraries were once
> particularly fragile, but that is mostly just a bad rememberance these
> days.

hmmm. I'm not sure I understand it yet... It's clear that they all 
release memory + close files etc. At least static allocated memory is 
surely released. What happens to memory/objects, allocated by "new" at 
termination? We know that destructors to classes are not called. Is it a 
memory leak or not? Is that a clear question? I hope there's a clear 
answer...?

> It can be that for some or even many apps, process cleanup by the OS is
> sufficient. This should be a conscious choice, though, knowing what is
> safe and what is not, rather than left to chance out of ignorance.
> Destructors can do much more than simply release memory.
>
> The largest problem in self-education is what you don't know about what
> you need to know. It looks like you're coming to grips with process flow
> on termination. You need to now understand more about what the OS thinks
> of a process, its resources and lifetime. It's a long path, and aside
> from my passing mention of destructors above, not language specific and
> probably should be moved to a different newsgroup.

Not sure if we're talking about the same thing anymore... See my 
question above.. Thank you!

[toc] | [prev] | [next] | [standalone]

#12979

On 2 Jan., someone wrote:
> hmmm. I'm not sure I understand it yet... It's clear that they all
> release memory + close files etc. At least static allocated memory is
> surely released.


The distinction between "static allocated memory" and dynamically
allocated memory only exists within the scope of the programming
language. Operating Systems make a distinction between heap and stack
memory. In most cases "static memory" will be located on the stack and
dynamic memory on the heap, but that is up to the implementation of
the compiler.

What is guaranteed by the OS is that both stack and heap memory will
be released upon process termination. Even more, Windows guarantees
that memory in its numerous sub-systems like GDI and COM will be
released.


> What happens to memory/objects, allocated by "new" at
> termination? We know that destructors to classes are not called.
> Is it a memory leak or not?

Destructors and memory management are pretty tightly coupled (new "="
constructor, delete "=" destructor), but there are (corner) cases with
placement new where destructors will be explicitely called without a
matching "delete". This would still count as a memory leak.


Is that a clear question? I hope there's a clear
> answer...?

At least it is a clear question.

We had lots of discussion about whether an allocation with "new" still
counts as a memory leak when the programmer intentionally left out the
matching "delete" because the OS will re-claim the memory anyway. I
tend to say that this should not be considered a memory leak, even if
this makes the definition of a memory leak a bit harder.

Regards,
Stuart

[toc] | [prev] | [next] | [standalone]

#12983

On 01/02/2012 01:32 PM, Stefan Ensslen wrote:
> On 2 Jan., someone wrote:
>> hmmm. I'm not sure I understand it yet... It's clear that they all
>> release memory + close files etc. At least static allocated memory is
>> surely released.
>
>
> The distinction between "static allocated memory" and dynamically
> allocated memory only exists within the scope of the programming
> language. Operating Systems make a distinction between heap and stack
> memory. In most cases "static memory" will be located on the stack and
> dynamic memory on the heap, but that is up to the implementation of
> the compiler.
>
> What is guaranteed by the OS is that both stack and heap memory will
> be released upon process termination. Even more, Windows guarantees
> that memory in its numerous sub-systems like GDI and COM will be
> released.

But not linux/mac os X, meaning in this area Windows is more "safe" ?

>> What happens to memory/objects, allocated by "new" at
>> termination? We know that destructors to classes are not called.
>> Is it a memory leak or not?
>
> Destructors and memory management are pretty tightly coupled (new "="
> constructor, delete "=" destructor), but there are (corner) cases with
> placement new where destructors will be explicitely called without a
> matching "delete". This would still count as a memory leak.

Ok.

> Is that a clear question? I hope there's a clear
>> answer...?
>
> At least it is a clear question.
>
> We had lots of discussion about whether an allocation with "new" still
> counts as a memory leak when the programmer intentionally left out the
> matching "delete" because the OS will re-claim the memory anyway. I
> tend to say that this should not be considered a memory leak, even if
> this makes the definition of a memory leak a bit harder.

Ok, thank you very much - I think I understand now.

[toc] | [prev] | [next] | [standalone]

#12988

Op 02-Jan-12 17:40, someone schreef:
> On 01/02/2012 01:32 PM, Stefan Ensslen wrote:
>> On 2 Jan., someone wrote:
>>> hmmm. I'm not sure I understand it yet... It's clear that they all
>>> release memory + close files etc. At least static allocated memory is
>>> surely released.
>>
>>
>> The distinction between "static allocated memory" and dynamically
>> allocated memory only exists within the scope of the programming
>> language. Operating Systems make a distinction between heap and stack
>> memory. In most cases "static memory" will be located on the stack and
>> dynamic memory on the heap, but that is up to the implementation of
>> the compiler.
>>
>> What is guaranteed by the OS is that both stack and heap memory will
>> be released upon process termination. Even more, Windows guarantees
>> that memory in its numerous sub-systems like GDI and COM will be
>> released.
>
> But not linux/mac os X, meaning in this area Windows is more "safe" ?

Neither Linux nor Mac OSX have GDI and COM. The bottom line is that 
those operating systems will release resources claimed on behalf of the 
process when the process ceases to exist, regardless of whether the 
process releases those resources itself or not.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web