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!