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

#13034 — Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND?

On 2012-01-03 02:30, LR wrote:
> someone wrote:
>> On 01/02/2012 08:47 PM, LR wrote:
>>> someone wrote:
>>>> On 01/02/2012 03:11 AM, LR wrote:
>>>>> someone wrote:
>
>> (now I only need to somehow detect that std::vector destructors are also
>> being called when exit() happens, just so I can sleep better at night) -
>> I just wrote about this concern in another reply...
>
> Write a little class that prints something in the dtor.  Then try it in
> a std::vector.  This is why std::shared_ptr can clean up after itself.
> std::vector tries to dtor every entry, and std::shared_ptr dtors the
> thing it points to, if there is only one point to the thing left.
>
> For example, I wrote this little function using the class hierarchy I
> previously posted, (I compiled this using a recent version of MinGW with
> -std=c++0x
>
> void g() {
>      std::shared_ptr<DrawObjectBase>  t1(new Star());
>      std::cout<<  "t1.use_count() "<<  t1.use_count()<<  std::endl;
>      std::shared_ptr<DrawObjectBase>  t2(t1);
>      std::cout<<  "t1.use_count() "<<  t1.use_count()<<  std::endl;
>      std::cout<<  "t2.use_count() "<<  t2.use_count()<<  std::endl;
>      t1->draw("AA");
>      t2->draw("BB");
> }

What exactly is your command line for compiling?

> and the output was
>
> DrawObjectBase(0x3e2768)
> Star(0x3e2768)
> t1.use_count() 1
> t1.use_count() 2
> t2.use_count() 2
> Star::draw(0x3e2768,AA)
> Star::draw(0x3e2768,BB)
> ~Star(0x3e2768)
> ~DrawObjectBase(0x3e2768)

Would be much better if I could run it too :-)

I installed minGW on linux and tried this:

x86_64-w64-mingw32-c++ -std=c++0x test.cpp
(response: LOTS of errors, like yesterday)


>> class gearClass : public drawableObj
>> {
>>     // private
>>     // public
>>
>>     gearClass::gearClass( ... ) // constructor
>>     {
>>       pObjs.push_back((gearClass*) this); //<---- HERE IS THE ANSWER
>>       ...
>>       ... etc
>>     }
>> }
>>
>> Isn't that an appropriate way of doing it?
>
> I think that you're coupling, that is, creating a dependency in your
> class on a global.  I don't think that's a good idea.

But I need something that is global. Because it's impossible to pass any 
data into the glutmainloop, if nothing is global.

The answer is just: What global parameter is sufficient? What do you 
propose instead of the way I did it, thanks?

> Why are you casting the this pointer of gearClass to (gearClass*)?
> Isn't it already a (gearClass*)?

Ah, stupid - my mistake. I removed it now, thanks a lot (I previously 
had some trouble with referencing gearClass with a pointer to the base 
class, and before I made that specific member function virtual, I had to 
make such a cast like this in my poorly written noob code :-) )!

Thank you very much for spotting it and telling/asking about it! It's 
fixed now (cast removed...)...

>>>>      return(0); // never comes here - just to satisfy compiler...
>>>
>>> Odd, because it shouldn't be required at all.
>>
>> Sure? Because main is supposed to return an integer, right?...
>
> I'm sure.  Because main is not required to return an int.  I'm surprised
> that compilers are still complaining about this.  Time to upgrade?

Honestly, I cannot remember why I made main return an int. Maybe I just 
did it because for many years ago I learnt it or maybe I found something 
(old, posts perhaps) on google, telling me to do it...

>>>> class drawableObj
>>>> {
>>>>     // private: // protected: // I don't have anything here
>>>>
>>>>     public:
>>>>      // global+static pointer to all GRAPHICAL objs:
>>>>      static vector<drawableObj*>   pObjs;
>>>
>>> Why is this static?  Why not just make it a member class?
>>
>> Exactly! I'm glad that you ask... Actually, since I put (with global
>> scope) - in top of main():
>>
>> drawableObj allObjs;
>
> [snip stuff about static]
>> What's it complaining about?
>
> I'm not sure.

Damn... Ok, I'll look at it later - maybe in the weekend and try to fix 
this static problem...

Thanks for looking...


>>>> class gearClass : public drawableObj
>>> Ok, now I'm confused.  Is drawableObj some sort of polymorphic base
>>> class, or is it a container for a whole bunch of objects.
>>
>> Yes, isn't it both? I think it's a polymorphic base class (although I'm
>> not too experienced with this) !
>
> Why is it both?  Why not make two classes, one is the base class of Gear
> and whatever other classes you intend to have a draw method that
> inherits from the base.  And another class that is a container for a
> collection of instances of these classes.  Or rather a container for a
> collection of pointers to instances of these classes.

Maybe... Could possible be made... But why make 2 global classes, when I 
can put everything in a single global class?

*That* was my rationale (best to have one single global class to put all 
things required by glut and elsewhere, for purpose of simplicity)...

>>> Coupling your class with an external object made elsewhere probably
>>> limits the utility of the class.
>>
>> Hmmm. Not sure I understand exactly what I'm doing... Please elaborate -
>> I also don't understand fully how it "limits the utility of the class"
>> (because I'm not completely sure of what I'm doing)...
>
> For one thing, when you bury uses of your global in classes like Gear,
> you're letting yourself in for a lot of work if things ever changes.

Ok, but the "drawableObj" base class, I think is something I want to 
keep. I'll just make different derived classes, in order to paint/draw 
different graphical stuff on the screen...

>>>> drawableObj::~drawableObj() // destructor
>>>
>>>> 		if ( ((gearClass*) drawableObj::pObjs[z])->memAllocated )
>>>> 		   delete ((gearClass*) drawableObj::pObjs[z]);
>>> Or use a shared pointer and avoid this.
>>
>> But the idea is that I wanted polymorphism for all different kinds of
>> graphical objects. By shared pointer, do you mean a global pointer? I
>> don't like that idea... Here's why:
>
> All different kinds?  Or all different kinds that inherit a draw method?

I make (what I call) my "graphical objects" myself and I make them so 
they *all* inherit a draw method... If they don't have a draw-method, 
then they're not something I plan on deriving from drawableObj...

And there's nothing else than graphical objects (with a draw method) in 
my program... Because only the graphical objects needs some "global" 
access from "glutmainloop"...

> It is possible to make collections of objects that have different
> interfaces.  You may want to take a look at boost::variant.

hmmm. I found an interesting description here:

http://www.boost.org/doc/libs/1_48_0/doc/html/variant.html

Might take a closer look at it, in the weekend (=more spare time), thank 
you...

> Some of what you've written implies that you not all of your classes
> will share the same base class with gearClass.  Is this true?

No, sorry, not true. All my classes will derive from the same base class 
as gearClass... Then I use polymorphism inside glutmainloop to update 
the graphical animation on the screen...

>> If I'm correct, then a shared pointer could only be used to point to all
>> (gearClass*) drawableObj (gearClass is a derived class, from
>> drawableObj). But I want the program to be able to handle more than one
>> class. Currently I only have gearClass deriving from drawableObj.
>> Suppose later I add extra classes like: cylinder, sphere, box, all 3
>> deriving from base class "drawableObj". Then I would like one single
>> "interface" to all those member functions that e.g. updates the display
>
> Like the Star and Planet classes in my previous example?  Or is there

Exactly! At least I think so, based on the output you showed (because I 
haven't compiled it without errors yet, will try a bit later again)...

> something else that you'd like all of these classes to do?

Nope... They just need to update an animation, so I only need something 
like your draw-function in the Star and Planet-example...

> In any case, you'd use std::shared_ptr to point to the base class of
> your classes.  Not to each individual class. In your case,
> std::shared_ptr<drawableObj>. Then, so long as your other classes,
> cylinder, sphere and box all inherit from drawableObj, you'll get the
> behavior you want for each class, ie whatever implementation you've
> written for void draw() for each class is what you'll get.

Yep, thank you. It's great...

> You may also want to have a look at dynamic_cast.

Sorry, for what (it's true that I need it, because I suck so bad at 
using and understanding it, but maybe you're saying it because I do 
something wrong in my program?)? :-)

>> 	(drawableObj::pObjs[z])->updateDisplay(); // could be any kind
>
> Any kind of pointer to a drawableObj.  So far you only have gearClass.

Yep (more will come within a few weeks) ! :-)

>>> FWIW, here's my suggestion. Most of it is just trace so you can see
>>> what's going on. I consider this to be a snippet. For example, it would
>>> be a better idea to put the classes and implementations in header and
>>> source files.
>>
>> Ok - thank you. But first I want to compile it - then I can move it into
>> separate files...
>
> I wouldn't bother.  It's just an example.

Ok.

>> What compiler are you using? I get quite some errors with:
>>
>> g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
>
> I tried MinGW 4.6.1.  If you change the std::tr1::.. to std::.. it
> should compile.  I also used  the -std=c++0x compiler argument.


WOW... I just made it work, with these two tiny changes, see below!


>>   It
>> doesn't compile, so I'll just write what my compiler says:
>
> The above ought to take care of the errors you posted. I hope.

You're absolutely right... Thank you very much. I'll study the example a 
bit closer tonight when I come home (I am at work, currently)...

Incredible how many errors just disappeared by:

1) Search and replace std::tr1::.. to std::...

2) Compile like this: g++ -std=c++0x -Wall test.cpp


Thank you!

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

#13048 — Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND?

someone wrote:
> On 2012-01-03 02:30, LR wrote:
>> someone wrote:
>>> On 01/02/2012 08:47 PM, LR wrote:
>>>> someone wrote:
>>>>> On 01/02/2012 03:11 AM, LR wrote:
>>>>>> someone wrote:


>>> class gearClass : public drawableObj
>>> 
>>>
>>>     gearClass::gearClass( ... ) // constructor
>>>     {
>>>       pObjs.push_back((gearClass*) this); //<---- HERE IS THE ANSWER
>>>
>>> Isn't that an appropriate way of doing it?
>>
>> I think that you're coupling, that is, creating a dependency in your
>> class on a global.  I don't think that's a good idea.
> 
> But I need something that is global. Because it's impossible to pass any 
> data into the glutmainloop, if nothing is global.

Yes.  But you're filling your global with pointers to drawableObjs.  The
global that you use for that should have a method that more or less
takes a pointer to a drawableObj and sticks it in a container in the
instance of the global class.

I'm not saying that what you suggest isn't possible.  I just think it
makes for some awkwardness if you ever want to use a different
container, or use the class for some code where the container you're
using isn't available.

But in some ways it's an aesthetic choice, not a technical one.


> 
> The answer is just: What global parameter is sufficient? What do you 
> propose instead of the way I did it, thanks?

See my previously posted example.




> 
>>>>> class gearClass : public drawableObj
>>>> Ok, now I'm confused.  Is drawableObj some sort of polymorphic base
>>>> class, or is it a container for a whole bunch of objects.
>>>
>>> Yes, isn't it both? I think it's a polymorphic base class (although I'm
>>> not too experienced with this) !
>>
>> Why is it both?  Why not make two classes, one is the base class of Gear
>> and whatever other classes you intend to have a draw method that
>> inherits from the base.  And another class that is a container for a
>> collection of instances of these classes.  Or rather a container for a
>> collection of pointers to instances of these classes.
> 
> Maybe... Could possible be made... But why make 2 global classes, when I 
> can put everything in a single global class?

Because it's confusing.  IMHO it's nice to ask about a class, What does
it do or what is its purpose?

A floor wax or a dessert topping but not both.
http://snltranscripts.jt.org/75/75ishimmer.phtml

// the thing that is inherited by gear, sphere, etc..
class DrawableObjectBase;

// an instance of this will contains the pointers to your instances of
instances of classes that inherit from DrawableObjectBase.
class DrawableObjectsContainer;

I think combining those purposes into,
class DrawableObjectBaseAndDrawableObjectsContainer;
just makes trouble.

But maybe that's just me.  YMMV.


> 
> *That* was my rationale (best to have one single global class to put all 
> things required by glut and elsewhere, for purpose of simplicity)...

If it works for you, fine. I think it makes things harder and more
difficult to understand.  But IMHO you ought to do things that are clear
for you.

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

#13087 — Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND?

On 01/03/2012 11:46 PM, LR wrote:
> someone wrote:
>> On 2012-01-03 02:30, LR wrote:
>>> someone wrote:
>>>> On 01/02/2012 08:47 PM, LR wrote:
>>>>> someone wrote:
>>>>>> On 01/02/2012 03:11 AM, LR wrote:
>>>>>>> someone wrote:
>
>
>>>> class gearClass : public drawableObj
>>>>
>>>>
>>>>      gearClass::gearClass( ... ) // constructor
>>>>      {
>>>>        pObjs.push_back((gearClass*) this); //<---- HERE IS THE ANSWER
>>>>
>>>> Isn't that an appropriate way of doing it?
>>>
>>> I think that you're coupling, that is, creating a dependency in your
>>> class on a global.  I don't think that's a good idea.
>>
>> But I need something that is global. Because it's impossible to pass any
>> data into the glutmainloop, if nothing is global.
>
> Yes.  But you're filling your global with pointers to drawableObjs.  The
> global that you use for that should have a method that more or less
> takes a pointer to a drawableObj and sticks it in a container in the
> instance of the global class.

Ok... I'll think about it, maybe you're right :-)

> I'm not saying that what you suggest isn't possible.  I just think it
> makes for some awkwardness if you ever want to use a different
> container, or use the class for some code where the container you're
> using isn't available.
>
> But in some ways it's an aesthetic choice, not a technical one.

Roger that.

>> The answer is just: What global parameter is sufficient? What do you
>> propose instead of the way I did it, thanks?
>
> See my previously posted example.

Ok.

>>>>>> class gearClass : public drawableObj
>>>>> Ok, now I'm confused.  Is drawableObj some sort of polymorphic base
>>>>> class, or is it a container for a whole bunch of objects.
>>>>
>>>> Yes, isn't it both? I think it's a polymorphic base class (although I'm
>>>> not too experienced with this) !
>>>
>>> Why is it both?  Why not make two classes, one is the base class of Gear
>>> and whatever other classes you intend to have a draw method that
>>> inherits from the base.  And another class that is a container for a
>>> collection of instances of these classes.  Or rather a container for a
>>> collection of pointers to instances of these classes.
>>
>> Maybe... Could possible be made... But why make 2 global classes, when I
>> can put everything in a single global class?
>
> Because it's confusing.  IMHO it's nice to ask about a class, What does
> it do or what is its purpose?
>
> A floor wax or a dessert topping but not both.
> http://snltranscripts.jt.org/75/75ishimmer.phtml
>
> // the thing that is inherited by gear, sphere, etc..
> class DrawableObjectBase;
>
> // an instance of this will contains the pointers to your instances of
> instances of classes that inherit from DrawableObjectBase.
> class DrawableObjectsContainer;
>
> I think combining those purposes into,
> class DrawableObjectBaseAndDrawableObjectsContainer;
> just makes trouble.
>
> But maybe that's just me.  YMMV.

I see...

But maybe you're right... I think you're more professional than me :-)
I'll think about it and maybe redo it later when I have more time...

>> *That* was my rationale (best to have one single global class to put all
>> things required by glut and elsewhere, for purpose of simplicity)...
>
> If it works for you, fine. I think it makes things harder and more
> difficult to understand.  But IMHO you ought to do things that are clear
> for you.

It's very nice to hear/read how other people would do it... Thank you 
very much for that! :-)

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

#13101 — Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND?

someone wrote:

> But maybe you're right... 

Someone thinks I might be right.  An internet first. ;)


> I think you're more professional than me :-)

No.  Like Mr. Steinbach's recent thread, I just have more to repent. :-(

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

#13050 — Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND?

On Tue, 03 Jan 2012 19:08:45 +0100, someone <newsboost@gmail.com> 
wrote:
> >>>>      return(0); // never comes here - just to satisfy 
compiler...
> >>>
> >>> Odd, because it shouldn't be required at all.
> >>
> >> Sure? Because main is supposed to return an integer, right?...
> >
> > I'm sure.  Because main is not required to return an int.  I'm 
surprised
> > that compilers are still complaining about this.  Time to upgrade?


> Honestly, I cannot remember why I made main return an int. Maybe I 
just 
> did it because for many years ago I learnt it or maybe I found 
something 
> (old, posts perhaps) on google, telling me to do it...

um... main *does* need to return an int.

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

#13059 — Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND?

Garrett Hartshaw wrote:
> On Tue, 03 Jan 2012 19:08:45 +0100, someone <newsboost@gmail.com> 
> wrote:
>>>>>>      return(0); // never comes here - just to satisfy 
> compiler...
>>>>>
>>>>> Odd, because it shouldn't be required at all.
>>>>
>>>> Sure? Because main is supposed to return an integer, right?...
>>>
>>> I'm sure.  Because main is not required to return an int.  I'm 
> surprised
>>> that compilers are still complaining about this.  Time to upgrade?
> 
> 
>> Honestly, I cannot remember why I made main return an int. Maybe I 
> just 
>> did it because for many years ago I learnt it or maybe I found 
> something 
>> (old, posts perhaps) on google, telling me to do it...
> 
> um... main *does* need to return an int.

Yes.  I could have said that better. main doesn't have to have a return
statement in it.

From n3242 Main function 3.6.1.5
[...] If control reaches the end of main without encountering a return
statement, the effect is that of executing
              return 0;

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

#13063 — Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND?

On Tue, 03 Jan 2012 21:51:57 -0500, LR <lruss@superlink.net> wrote:
> Garrett Hartshaw wrote:
> > On Tue, 03 Jan 2012 19:08:45 +0100, someone <newsboost@gmail.com> 
> > wrote:
> >>>>>>      return(0); // never comes here - just to satisfy 
> > compiler...
> >>>>>
> >>>>> Odd, because it shouldn't be required at all.
> >>>>
> >>>> Sure? Because main is supposed to return an integer, right?...
> >>>
> >>> I'm sure.  Because main is not required to return an int.  I'm 
> > surprised
> >>> that compilers are still complaining about this.  Time to 
upgrade?
> > 
> > 
> >> Honestly, I cannot remember why I made main return an int. Maybe 
I 
> > just 
> >> did it because for many years ago I learnt it or maybe I found 
> > something 
> >> (old, posts perhaps) on google, telling me to do it...
> > 
> > um... main *does* need to return an int.


> Yes.  I could have said that better. main doesn't have to have a 
return
> statement in it.


> From n3242 Main function 3.6.1.5
> [...] If control reaches the end of main without encountering a 
return
> statement, the effect is that of executing
>               return 0;

Ahh... most compilers will still give an error about not returning a 
value from a non-void function. It's probably good to make the return 
0 explicit anyways.

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

#13085 — Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND?

Garrett Hartshaw wrote:
> On Tue, 03 Jan 2012 21:51:57 -0500, LR <lruss@superlink.net> wrote:

> 
>> From n3242 Main function 3.6.1.5
>> [...] If control reaches the end of main without encountering a 
> return
>> statement, the effect is that of executing
>>               return 0;
> 
> Ahh... most compilers will still give an error about not returning a 
> value from a non-void function. It's probably good to make the return 
> 0 explicit anyways.

Good point. Although the compilers I use don't seem to have that problem.

But speaking of that, since the OP has some portability issues, I should
add that using boost's shared_ptr might be the thing to do, if that's
what the ends up doing, to avoid the whole std:: v. std::tr1 problem if
that's an issue.

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

#13088 — Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND?

On 01/04/2012 08:24 PM, LR wrote:
> Garrett Hartshaw wrote:
>> On Tue, 03 Jan 2012 21:51:57 -0500, LR<lruss@superlink.net>  wrote:
>
>>
>>>  From n3242 Main function 3.6.1.5
>>> [...] If control reaches the end of main without encountering a
>> return
>>> statement, the effect is that of executing
>>>                return 0;
>>
>> Ahh... most compilers will still give an error about not returning a
>> value from a non-void function. It's probably good to make the return
>> 0 explicit anyways.
>
> Good point. Although the compilers I use don't seem to have that problem.
>
> But speaking of that, since the OP has some portability issues, I should
> add that using boost's shared_ptr might be the thing to do, if that's
> what the ends up doing, to avoid the whole std:: v. std::tr1 problem if
> that's an issue.

I don't even know what std:: v and std::tr1 means, but I'll look at 
std::tr1 in the weekend and study the previously-posted "planets"-code 
which use it...

Anyway - I'll also read about boost's shared_ptr in the weekend so I'll 
hopefully understand it (or the most important things in it) within 1 
week...

Thank you all...

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

#13100 — Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND?

someone wrote:

> I don't even know what std:: v and std::tr1 means, but I'll look at 
> std::tr1 in the weekend and study the previously-posted "planets"-code 
> which use it...

Just that you're using more than one compiler.

Of the two I currently use, one of them has std::tr1::shared_ptr and the
other one, which I think is more current, has std::shared_ptr.

So maybe this is something you want to check if you have to write
portable code.

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

#13104 — Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION FOUND?

On 01/05/2012 12:51 AM, LR wrote:
> someone wrote:
>
>> I don't even know what std:: v and std::tr1 means, but I'll look at
>> std::tr1 in the weekend and study the previously-posted "planets"-code
>> which use it...
>
> Just that you're using more than one compiler.
>
> Of the two I currently use, one of them has std::tr1::shared_ptr and the
> other one, which I think is more current, has std::shared_ptr.
>
> So maybe this is something you want to check if you have to write
> portable code.

Yes, definately, thanks... I'll look at it and google for previous 
discussions/examples about it and perhaps ask in a new thread, if things 
get too complicated for me :-)

Thank you.

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

#12965

On Mon, 02 Jan 2012 00:49:45 +0100, someone <newsboost@gmail.com> 
wrote:
> On 01/01/2012 10:03 AM, Juha Nieminen wrote:
> > someone<newsboost@gmail.com>  wrote:
> >> I don't think I can avoid it... I have some 20.000 points that 
needs
> >> real fast access to screen buffer in opengl application...
> >
> >    What exactly does this have to do with derived classes and 
virtual
> > destructors?


> I just don't want static allocation, because only at runtime I know 
how 
> large arrays I need. So I'm saying I need dynamic allocation and I 
> cannot avoid that. Then std::vector<> and "new" both have the same 
> problem, with no cleaning up if there's an exit() somewhere.


> As far as I can see, the solution is that I learn about smart 
pointers, 
> c++11 or std::tr1. And if that fails, I'll look at std::auto_ptr 
(though 
> not recommended from people in here)...

the smart pointers will do no better then std::vector if exit() is 
called (which is why exit should be avoided). I think that your 
problem could be solved by calling the destructors from atexit.

I would still recommend looking into smart pointers for the future.

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

#12968

On 01/02/2012 05:02 AM, Garrett Hartshaw wrote:
> On Mon, 02 Jan 2012 00:49:45 +0100, someone <newsboost@gmail.com> wrote:
>
>> As far as I can see, the solution is that I learn about smart
> pointers,
>> c++11 or std::tr1. And if that fails, I'll look at std::auto_ptr
> (though
>> not recommended from people in here)...
>
> the smart pointers will do no better then std::vector if exit() is
> called (which is why exit should be avoided). I think that your problem
> could be solved by calling the destructors from atexit.
>
> I would still recommend looking into smart pointers for the future.

Great Garret - thanks, agreed I'll look into it and learn the idea 
behind using it...

Also: Please comment on my other reply ( with subject line: Re: noob 
question - destructors - freeing memory... POSSIBLE SOLUTION FOUND? )

I'm very interested in hearing what people has to say about that :-)

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

#12973

"Garrett Hartshaw" <ghartshaw@gmail.com> ha scritto nel messaggio
news:almarsoft.1290150499951813836@news.eternal-september.org...

possible because i'm an hobby programmer or
possible have limitating experience
but i not found in asm/C/ C++/one problem
when the program has to end
and allow compiler to clear his memory call destrctuors etc
even if i not remember i call atexit() function

have all you Good 2012

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

#12972

someone <newsboost@gmail.com> wrote:
> On 01/01/2012 10:03 AM, Juha Nieminen wrote:
>> someone<newsboost@gmail.com>  wrote:
>>> I don't think I can avoid it... I have some 20.000 points that needs
>>> real fast access to screen buffer in opengl application...
>>
>>    What exactly does this have to do with derived classes and virtual
>> destructors?
> 
> I just don't want static allocation, because only at runtime I know how 
> large arrays I need.

  I still don't see the connection with base and derived classes in your
original post.

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

#12987

On 01/02/2012 07:22 AM, Juha Nieminen wrote:
> someone<newsboost@gmail.com>  wrote:
>> On 01/01/2012 10:03 AM, Juha Nieminen wrote:
>>> someone<newsboost@gmail.com>   wrote:
>>>> I don't think I can avoid it... I have some 20.000 points that needs
>>>> real fast access to screen buffer in opengl application...
>>>
>>>     What exactly does this have to do with derived classes and virtual
>>> destructors?

Ok, it has that to do with derived classes and virtual destructors, that 
I use derived classes and virtual destructors in a bigger program. I 
then found out that (at least not all) my destructors where called (in 
the bigger program) and then I sought a solution I could implement in my 
opengl-program - to do that, I posted a minimal example...

I also posted a longer code sequence with slightly modified subject like...

>> I just don't want static allocation, because only at runtime I know how
>> large arrays I need.
>
>    I still don't see the connection with base and derived classes in your
> original post.

Sorry, I'm not sure I understand it then... The original post had many 
similarities with my working code... The similarities are/is the 
connection... Do I misunderstand ?

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

#12907

someone wrote:
>
> ========
>
> 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(...)
> {
>   ...
>   Derived d1();
>   return 0; // or exit(1); if something went wrong somewhere
> }
>

This actually doesn't create an object, but declares a function d1 
that returns a Derived object. If you compare

Derived d1();

to the more common

int f();

you will see the similarity!


Bo Persson

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

#12920

On 12/31/2011 12:51 PM, Bo Persson wrote:
> someone wrote:
>>
>> ========
>>
>> 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(...)
>> {
>>    ...
>>    Derived d1();
>>    return 0; // or exit(1); if something went wrong somewhere
>> }
>>
>
> This actually doesn't create an object, but declares a function d1
> that returns a Derived object. If you compare
>
> Derived d1();
>
> to the more common
>
> int f();
>
> you will see the similarity!
>
>
> Bo Persson

Ok, you're right... Then:

Derived d1;

Should be an object, that's what I think I meant :-)

[toc] | [prev] | [standalone]

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

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

csiph-web