Re: noob question - destructors - freeing memory... POSSIBLE SOLUTION
FOUND?
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");
}
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)
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.
Why are you casting the this pointer of gearClass to (gearClass*)?
Isn't it already a (gearClass*)?
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?
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.
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.
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.
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?
It is possible to make collections of objects that have different
interfaces. You may want to take a look at boost::variant.
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?
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
something else that you'd like all of these classes to do?
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.
You may also want to have a look at dynamic_cast.
(drawableObj::pObjs[z])->updateDisplay(); // could be any kind
Any kind of pointer to a drawableObj. So far you only have gearClass.
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.
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.
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.