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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#12992

On 01/02/2012 07:14 PM, Dombo wrote:
>>> 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.

Ok, thanks.

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

#13165

In article <596ba0a4-5b2b-4c35-831c-ae7d8cd1cc37@d10g2000vbk.googlegroups.com>,
Stefan Ensslen  <stefan@zollsoft.de> wrote:
>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.

One day someone is going to think it's a cool idea that your objects are
in shared memory, or in some memory-mapped files, in which case you have
a losing ticket.

It's very nice when you get to the main() last line the same as the
first line: nothing.

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

#13167

"Joe keane" <jgk@panix.com> wrote in message 
news:jeak4q$ppm$1@reader1.panix.com...
> In article 
> <596ba0a4-5b2b-4c35-831c-ae7d8cd1cc37@d10g2000vbk.googlegroups.com>,
> Stefan Ensslen  <stefan@zollsoft.de> wrote:
>>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.
>
> One day someone is going to think it's a cool idea that your objects are
> in shared memory, or in some memory-mapped files, in which case you have
> a losing ticket.

Aren't those the precise conditions that the standard delete would cause 
problems? You would need a custom allocator, to start.

> It's very nice when you get to the main() last line the same as the
> first line: nothing.

Yup. Agree fully. With the addition that allocations made during 
initialization by static objects also follow suit.

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

#12964

On Mon, 02 Jan 2012 00:33:32 +0100, someone <newsboost@gmail.com> 
wrote:
> 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 ai> > 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.

glut calls exit() when the X button is pressed.
in freeglut you can tell it to return from glutMainLoop instead, I 
forget what you need to call. I personally wouldn't bother with 
either of them, as I usually use straight glx (because its easier to 
get a opengl 3 context), but you could have a look at have a look at 
glfw.

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

#12967

On 01/02/2012 04:54 AM, Garrett Hartshaw wrote:
> On Mon, 02 Jan 2012 00:33:32 +0100, someone <newsboost@gmail.com> wrote:
>> On 01/01/2012 04:54 PM, LR wrote:
>> > someone wrote:
>> >

>> > Depends on if it can be captured per ai> > 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.
>
> glut calls exit() when the X button is pressed.

Yep, thought so... In any case: I posted a possible solution elsewhere 
(and changed the subject-line, because there are so many answers now). 
Would be nice to hear your comments on my "possible solution"-subject 
post...

> in freeglut you can tell it to return from glutMainLoop instead, I
> forget what you need to call. I personally wouldn't bother with either
> of them, as I usually use straight glx (because its easier to get a
> opengl 3 context), but you could have a look at have a look at glfw.

Ah, interesting... I'm interested in doing everything crossplatform 
Windows/Linux. Learning/looking at glfw is on my "to-do list...", thanks 
a lot for the hints (just need some more time to learn all that I want 
to/would like to know)... :-)

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

#12951

On Dec 31 2011, 5:13 pm, someone <newsbo...@gmail.com> wrote:
> 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....

<snip>

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

you could get destructors to do the cleanup. For instance a log file
could be an object and its dtor could flush the log file, write an
error message etc. Quite often catching is the wrong thing to do.

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

yes. Is there some way to stop it doing this?

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

as someone else said, use atexit() to register a cleanup function.

<snip>

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

#12956

On 01/01/2012 10:38 PM, Nick Keighley wrote:
> On Dec 31 2011, 5:13 pm, someone<newsbo...@gmail.com>  wrote:
>> 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....
>
> <snip>
>
>>>      - 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).
>
> you could get destructors to do the cleanup. For instance a log file
> could be an object and its dtor could flush the log file, write an
> error message etc. Quite often catching is the wrong thing to do.

You're saying I should replace all my exit()-calls with something else, 
I think too...

>>> 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?
>
> yes. Is there some way to stop it doing this?
>
>> With exit(0) from glut, is there any solution to cleaning up and freeing
>> memory?
>
> as someone else said, use atexit() to register a cleanup function.

Ok, thanks - I'll look into that...

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

#12908

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

There are several reasons. One is that pointers are inherited from the 
C language, and are expected to behave the same as they did there. In 
C there are no destructors at all.

Another reason is that there can be several pointers pointing to the 
same object. How are they supposed to know which one should delete the 
object pointed to? Or if anyone should do that. Not all pointed-to 
objects are created by new.

{
    int i = 0;
    int* p = &i;
}

Here we should definitely *not* call delete p.


Bo Persson

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

#12892

On Sat, 31 Dec 2011 02:43:28 +0100, someone <newsboost@gmail.com> 
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...


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

A statically constructed object will be destroyed when the scope is 
left.

e.g destructors will be called in:
int main()
{
   Derived d;
   return 0;
}

A dynamically constructed object (created using new) is destroyed 
when delete is called.

e.g destructors called in this:
int main()
{
   Base * b = new Derived();
   delete b;
   return 0;
}

but not this:
int main()
{
   Base * b = new Derived();
   return 0;
}


When exit(int) is called, the program is terminated *without 
unwinding the stack* so no destructors are called.

When a execption is thrown and not caught, the program is terminated 
*with stack unwinding*, so static objects are destroyed.

Note: 
int main()
{
   Base * b = new Derived();
   throw std::exception();
   delete b;
   return 0;
}

In the above, the delete expression is never reached, so destructors 
are not called.
If this is an issue, a smart pointer (boost::shared_ptr, 
boost::scoped_ptr, etc:) should be used.

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

#12895

On 12/31/2011 04:50 AM, Garrett Hartshaw wrote:
> On Sat, 31 Dec 2011 02:43:28 +0100, someone <newsboost@gmail.com> wrote:
>> Hi

>> Please advice, thank you!
>
> A statically constructed object will be destroyed when the scope is left.
>
> e.g destructors will be called in:
> int main()
> {
> Derived d;
> return 0;
> }

Ah, stupid me. I thought I had tried the above, and that it didn't work 
- thank you very much. My mistake, maybe also in reply to MikeWhy...

> A dynamically constructed object (created using new) is destroyed when
> delete is called.
>
> e.g destructors called in this:
> int main()
> {
> Base * b = new Derived();
> delete b;
> return 0;
> }
>
> but not this:
> int main()
> {
> Base * b = new Derived();
> return 0;
> }
>

Yes, this is clear now, the static thing was a brain-something that hit 
me...

> When exit(int) is called, the program is terminated *without unwinding
> the stack* so no destructors are called.

Yes, clear.

> When a execption is thrown and not caught, the program is terminated
> *with stack unwinding*, so static objects are destroyed.

Aah, only static objects... DAMN...

> Note: int main()
> {
> Base * b = new Derived();
> throw std::exception();
> delete b;
> return 0;
> }
>
> In the above, the delete expression is never reached, so destructors are
> not called.

That is a big problem/issue in my program, I think...

So if I allocate memory in my constructor, and I never call the 
destructor and I keep running and exiting, running and exiting the 
program, then I end up using all my memory because I never free'd it?

> If this is an issue, a smart pointer (boost::shared_ptr,
> boost::scoped_ptr, etc:) should be used.

Ooh, damn...

I hoped, I could avoid having to learn something new and timeconsuming 
like boost...

Isn't there an easier solution without including more libraries?


Thank you very much, by the way!

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

#12900

someone wrote:
> On 12/31/2011 04:50 AM, Garrett Hartshaw wrote:
>> On Sat, 31 Dec 2011 02:43:28 +0100, someone <newsboost@gmail.com> wrote:

>> Note: int main()
>> {
>> Base * b = new Derived();
>> throw std::exception();
>> delete b;
>> return 0;
>> }
>>
>> In the above, the delete expression is never reached, so destructors are
>> not called.
> 
> That is a big problem/issue in my program, I think...
> 
> So if I allocate memory in my constructor, and I never call the 
> destructor and I keep running and exiting, running and exiting the 
> program, then I end up using all my memory because I never free'd it?

May I ask why you're allocating memory?  I mean why are you writing new
explicitly in your code? What are you trying to do?
> 
>> If this is an issue, a smart pointer (boost::shared_ptr,
>> boost::scoped_ptr, etc:) should be used.
> 
> Ooh, damn...
> 
> I hoped, I could avoid having to learn something new and timeconsuming 
> like boost...
> 
> Isn't there an easier solution without including more libraries?

What compiler and version are you using?  You may find what you need in
a header that shipped with your compiler.

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

#12901

On 12/31/2011 07:07 AM, LR wrote:
> someone wrote:
>> On 12/31/2011 04:50 AM, Garrett Hartshaw wrote:
>>> On Sat, 31 Dec 2011 02:43:28 +0100, someone<newsboost@gmail.com>  wrote:
>
>>> Note: int main()
>>> {
>>> Base * b = new Derived();
>>> throw std::exception();
>>> delete b;
>>> return 0;
>>> }
>>>
>>> In the above, the delete expression is never reached, so destructors are
>>> not called.
>>
>> That is a big problem/issue in my program, I think...
>>
>> So if I allocate memory in my constructor, and I never call the
>> destructor and I keep running and exiting, running and exiting the
>> program, then I end up using all my memory because I never free'd it?
>
> May I ask why you're allocating memory?  I mean why are you writing new
> explicitly in your code? What are you trying to do?

Because:

I have some graphical objects that should be displayed on the screen. 
When I instantiate these objects, I don't know how many coordinates 
there are. When I know it, I use new to allocate memory for x,y and 
z-coordinates. It's pretty lame, if I should not allocate memory 
dynamically... It's hard to believe, it is so cumbersome. It would also 
look bad if I separate the x,y and z-coordinates from the graphical 
objects themselves. And even that would not solve the 
call-the-destructor-problem to free memory.

>>> If this is an issue, a smart pointer (boost::shared_ptr,
>>> boost::scoped_ptr, etc:) should be used.
>>
>> Ooh, damn...
>>
>> I hoped, I could avoid having to learn something new and timeconsuming
>> like boost...
>>
>> Isn't there an easier solution without including more libraries?
>
> What compiler and version are you using?  You may find what you need in
> a header that shipped with your compiler.

1) g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.

and

2) Visual studio 2011

= (crossplatform)

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

#12905

On Dec 31, 7:54 am, someone <newsbo...@gmail.com> wrote:
> On 12/31/2011 07:07 AM, LR wrote:

<snip>

> > May I ask why you're allocating memory?  I mean why are you writing new
> > explicitly in your code? What are you trying to do?
>
> Because:
>
> I have some graphical objects that should be displayed on the screen.
> When I instantiate these objects, I don't know how many coordinates
> there are. When I know it, I use new to allocate memory for x,y and
> z-coordinates. It's pretty lame, if I should not allocate memory
> dynamically... It's hard to believe, it is so cumbersome.

would std::vector solve your problem? Something like this:-

// vec.cpp

#include <vector>

struct Point
{
	int x;
	int y;
	int z;
};

void draw (std::vector<Point>& graphicalObject)
{
	// do whatever has to be done to draw the object
}

// make an object with pointCount points
void makeObject (int pointCount)
{
	std::vector<Point> graphicalObject(pointCount);
	// initialise it somehow
	draw (graphicalObject);
	// graphicalObject and all its points destroyed here
}

int main ()
{
	int n = 10;   // determine number of points somehow
	makeObject (n);
}

<snip>

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

#12922

On 12/31/2011 11:05 AM, Nick Keighley wrote:
> On Dec 31, 7:54 am, someone<newsbo...@gmail.com>  wrote:
>> On 12/31/2011 07:07 AM, LR wrote:
>
> <snip>
>
>>> May I ask why you're allocating memory?  I mean why are you writing new
>>> explicitly in your code? What are you trying to do?
>>
>> Because:
>>
>> I have some graphical objects that should be displayed on the screen.
>> When I instantiate these objects, I don't know how many coordinates
>> there are. When I know it, I use new to allocate memory for x,y and
>> z-coordinates. It's pretty lame, if I should not allocate memory
>> dynamically... It's hard to believe, it is so cumbersome.
>
> would std::vector solve your problem? Something like this:-

Uuuuuh. sounds really ugly with a lot of overhead in my ears... Not sure 
if it'll work, though...

> // vec.cpp
>
> #include<vector>
>
> struct Point
> {
> 	int x;
> 	int y;
> 	int z;
> };
>
> void draw (std::vector<Point>&  graphicalObject)
> {
> 	// do whatever has to be done to draw the object
> }
>
> // make an object with pointCount points
> void makeObject (int pointCount)
> {
> 	std::vector<Point>  graphicalObject(pointCount);
> 	// initialise it somehow
> 	draw (graphicalObject);
> 	// graphicalObject and all its points destroyed here
> }
>
> int main ()
> {
> 	int n = 10;   // determine number of points somehow
> 	makeObject (n);
> }

Replace n = 10 with n = 20.000. Also it needs to be really really fast 
so openGL can make 60 FPS per seconds + all intermediate calculations...

You're saying that std::vector<> doesn't have the problem with not 
cleaning up if there's an exit() somewhere, right?

Looks slow to me, but haven't tried it...

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

#12952

On Dec 31 2011, 5:22 pm, someone <newsbo...@gmail.com> wrote:
> On 12/31/2011 11:05 AM, Nick Keighley wrote:
>
>
>
>
>
> > On Dec 31, 7:54 am, someone<newsbo...@gmail.com>  wrote:
> >> On 12/31/2011 07:07 AM, LR wrote:
>
> > <snip>
>
> >>> May I ask why you're allocating memory?  I mean why are you writing new
> >>> explicitly in your code? What are you trying to do?
>
> >> Because:
>
> >> I have some graphical objects that should be displayed on the screen.
> >> When I instantiate these objects, I don't know how many coordinates
> >> there are. When I know it, I use new to allocate memory for x,y and
> >> z-coordinates. It's pretty lame, if I should not allocate memory
> >> dynamically... It's hard to believe, it is so cumbersome.
>
> > would std::vector solve your problem? Something like this:-
>
> Uuuuuh. sounds really ugly with a lot of overhead in my ears... Not sure
> if it'll work, though...
>
>
>
>
>
> > // vec.cpp
>
> > #include<vector>
>
> > struct Point
> > {
> >    int x;
> >    int y;
> >    int z;
> > };
>
> > void draw (std::vector<Point>&  graphicalObject)
> > {
> >    // do whatever has to be done to draw the object
> > }
>
> > // make an object with pointCount points
> > void makeObject (int pointCount)
> > {
> >    std::vector<Point>  graphicalObject(pointCount);
> >    // initialise it somehow
> >    draw (graphicalObject);
> >    // graphicalObject and all its points destroyed here
> > }
>
> > int main ()
> > {
> >    int n = 10;   // determine number of points somehow
> >    makeObject (n);
> > }
>
> Replace n = 10 with n = 20.000. Also it needs to be really really fast
> so openGL can make 60 FPS per seconds + all intermediate calculations...
>
> You're saying that std::vector<> doesn't have the problem with not
> cleaning up if there's an exit() somewhere, right?

my earlier post was incorrect. exit() does not invoke any destructors.
idiot nick...

> Looks slow to me, but haven't tried it...- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

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

#12978

On Sun, 2012-01-01, Nick Keighley wrote:
> On Dec 31 2011, 5:22 pm, someone <newsbo...@gmail.com> wrote:
...
>> You're saying that std::vector<> doesn't have the problem with not
>> cleaning up if there's an exit() somewhere, right?
>
> my earlier post was incorrect. exit() does not invoke any destructors.
> idiot nick...

Still, the right approach that isn't to try to make your program play
nice with exit() randomly sprinkled in the code: the right approach is
to eliminate those exit()s.

It's typically trivial to find them by looking at the symbol tables in
the object code.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#12984

On 01/02/2012 01:17 PM, Jorgen Grahn wrote:
> On Sun, 2012-01-01, Nick Keighley wrote:
>> On Dec 31 2011, 5:22 pm, someone<newsbo...@gmail.com>  wrote:
> ...
>>> You're saying that std::vector<>  doesn't have the problem with not
>>> cleaning up if there's an exit() somewhere, right?
>>
>> my earlier post was incorrect. exit() does not invoke any destructors.
>> idiot nick...
>
> Still, the right approach that isn't to try to make your program play
> nice with exit() randomly sprinkled in the code: the right approach is
> to eliminate those exit()s.

With exceptions (try/catch), I guess...

> It's typically trivial to find them by looking at the symbol tables in
> the object code.

Uh, sounds very interesting. I googled a bit - it's something to do with 
the tool "nm" in linux, isn't it?

Here's "nm" on my main-file:

nm main.o0000000000000000 R Pi
000000000000092b t _GLOBAL__sub_I_Pi
                  U _Unwind_Resume
                  U _Z10screenshotPKcii
                  U _Z11makeLineSepv
00000000000008ca t _Z41__static_initialization_and_destruction_0ii
00000000000003b7 T _Z5timeri
00000000000000b5 T _Z7displayv
                  U _Z7findboxv
0000000000000176 T _Z7reshapeii
0000000000000000 T _Z7specialiii
000000000000034f T _Z8keyboardhii
0000000000000044 b _ZL4xPos
0000000000000048 b _ZL4yPos
                  U _ZN11drawableObj5pObjsE
                  U _ZN11drawableObjC1Ev
                  U _ZN11drawableObjD1Ev
                  U _ZN9gearClass11callFortranEv
                  U _ZN9gearClass13updateDisplayEv
                  U _ZN9gearClassC1E9gearTypesdiddddddddffd
0000000000000000 W _ZNKSt6vectorIP11drawableObjSaIS1_EE4sizeEv
                  U _ZNSolsEPFRSoS_E
                  U _ZNSolsEd
                  U _ZNSolsEm
0000000000000000 W _ZNSt6vectorIP11drawableObjSaIS1_EEixEm
                  U _ZNSt8ios_base4InitC1Ev
                  U _ZNSt8ios_base4InitD1Ev
                  U _ZSt4cout
                  U 
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
0000000000000040 b _ZStL8__ioinit
                  U _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
                  U _ZdlPv
                  U _Znwm
                  U __cxa_atexit
                  U __dso_handle
                  U __gxx_personality_v0
0000000000000020 B allObjs
                  U exit
                  U glClear
                  U glEnable
                  U glLoadIdentity
                  U glMatrixMode
                  U glPopMatrix
                  U glPushMatrix
                  U glShadeModel
                  U glTranslatef
                  U glViewport
                  U gluOrtho2D
                  U glutCreateWindow
                  U glutDisplayFunc
                  U glutInit
                  U glutInitDisplayMode
                  U glutInitWindowSize
                  U glutKeyboardFunc
                  U glutMainLoop
                  U glutPostRedisplay
                  U glutReshapeFunc
                  U glutSpecialFunc
                  U glutSwapBuffers
                  U glutTimerFunc
00000000000003dd T main
0000000000000010 B makeScreenshot
0000000000000000 D onlyWhiteGear
0000000000000008 B screenLimits
0000000000000000 B stopRotation
0000000000000004 D winSizeX
0000000000000008 D winSizeY


What's those hex-numbers?

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

#12990

On Mon, 2012-01-02, someone wrote:
> On 01/02/2012 01:17 PM, Jorgen Grahn wrote:
>> On Sun, 2012-01-01, Nick Keighley wrote:
>>> On Dec 31 2011, 5:22 pm, someone<newsbo...@gmail.com>  wrote:
>> ...
>>>> You're saying that std::vector<>  doesn't have the problem with not
>>>> cleaning up if there's an exit() somewhere, right?
>>>
>>> my earlier post was incorrect. exit() does not invoke any destructors.
>>> idiot nick...
>>
>> Still, the right approach that isn't to try to make your program play
>> nice with exit() randomly sprinkled in the code: the right approach is
>> to eliminate those exit()s.
>
> With exceptions (try/catch), I guess...

I don't follow you. Exceptions and exit() don't have much in common.

>> It's typically trivial to find them by looking at the symbol tables in
>> the object code.
>
> Uh, sounds very interesting. I googled a bit - it's something to do with 
> the tool "nm" in linux, isn't it?

Yes, that's the way I'd do it on that platform.

> Here's "nm" on my main-file:
>
> nm main.o0000000000000000 R Pi
> 000000000000092b t _GLOBAL__sub_I_Pi
>                   U _Unwind_Resume
>                   U _Z10screenshotPKcii
>                   U _Z11makeLineSepv
...
>                   U exit
...
>
> What's those hex-numbers?

I don't know exactly, but you can think of them as the address of the
function (or data) within that particular file.  'exit' is (U)ndefined
because it's something referenced from, not defined in, the file; thus
it has no address.

You should check if your nm accepts a -C option, by the way. It makes
C++ function names readable.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#12954

On Dec 31 2011, 5:22 pm, someone <newsbo...@gmail.com> wrote:
> On 12/31/2011 11:05 AM, Nick Keighley wrote:
> > On Dec 31, 7:54 am, someone<newsbo...@gmail.com>  wrote:
> >> On 12/31/2011 07:07 AM, LR wrote:


> >>> May I ask why you're allocating memory?  I mean why are you writing new
> >>> explicitly in your code? What are you trying to do?
>
> >> Because:
>
> >> I have some graphical objects that should be displayed on the screen.
> >> When I instantiate these objects, I don't know how many coordinates
> >> there are. When I know it, I use new to allocate memory for x,y and
> >> z-coordinates. It's pretty lame, if I should not allocate memory
> >> dynamically... It's hard to believe, it is so cumbersome.
>
> > would std::vector solve your problem? Something like this:-
>
> Uuuuuh. sounds really ugly with a lot of overhead in my ears... Not sure
> if it'll work, though...

I think it should.

> > // vec.cpp
>
> > #include<vector>
>
> > struct Point
> > {
> >    int x;
> >    int y;
> >    int z;
> > };
>
> > void draw (std::vector<Point>&  graphicalObject)
> > {
> >    // do whatever has to be done to draw the object
> > }
>
> > // make an object with pointCount points
> > void makeObject (int pointCount)
> > {
> >    std::vector<Point>  graphicalObject(pointCount);
> >    // initialise it somehow
> >    draw (graphicalObject);
> >    // graphicalObject and all its points destroyed here
> > }
>
> > int main ()
> > {
> >    int n = 10;   // determine number of points somehow
> >    makeObject (n);
> > }
>
> Replace n = 10 with n = 20.000. Also it needs to be really really fast
> so openGL can make 60 FPS per seconds + all intermediate calculations...

well new isn't cheap

> You're saying that std::vector<> doesn't have the problem with not
> cleaning up if there's an exit() somewhere, right?

vector calls the destructors for the objects it holds

> Looks slow to me, but haven't tried it

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

#12904

On Dec 31, 4:37 am, someone <newsbo...@gmail.com> wrote:
> On 12/31/2011 04:50 AM, Garrett Hartshaw wrote:
>
> > On Sat, 31 Dec 2011 02:43:28 +0100, someone <newsbo...@gmail.com> wrote:
> >> Hi
> >> Please advice, thank you!
>
> > A statically constructed object will be destroyed when the scope is left.
>
> > e.g destructors will be called in:
> > int main()
> > {
> > Derived d;
> > return 0;
> > }
>
> Ah, stupid me. I thought I had tried the above, and that it didn't work
> - thank you very much. My mistake, maybe also in reply to MikeWhy...
>
>
>
>
>
> > A dynamically constructed object (created using new) is destroyed when
> > delete is called.
>
> > e.g destructors called in this:
> > int main()
> > {
> > Base * b = new Derived();
> > delete b;
> > return 0;
> > }
>
> > but not this:
> > int main()
> > {
> > Base * b = new Derived();
> > return 0;
> > }
>
> Yes, this is clear now, the static thing was a brain-something that hit
> me...
>
> > When exit(int) is called, the program is terminated *without unwinding
> > the stack* so no destructors are called.
>
> Yes, clear.
>
> > When a execption is thrown and not caught, the program is terminated
> > *with stack unwinding*, so static objects are destroyed.
>
> Aah, only static objects... DAMN...
>
> > Note: int main()
> > {
> > Base * b = new Derived();
> > throw std::exception();
> > delete b;
> > return 0;
> > }
>
> > In the above, the delete expression is never reached, so destructors are
> > not called.
>
> That is a big problem/issue in my program, I think...
>
> So if I allocate memory in my constructor, and I never call the
> destructor and I keep running and exiting, running and exiting the
> program, then I end up using all my memory because I never free'd it?
>
> > If this is an issue, a smart pointer (boost::shared_ptr,
> > boost::scoped_ptr, etc:) should be used.
>
> Ooh, damn...
>
> I hoped, I could avoid having to learn something new and timeconsuming
> like boost...
>
> Isn't there an easier solution without including more libraries?

std::auto_ptr

though I believe this is now deprecated. Hasn't been removed though
and does the job.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web