Complex C++ prob: static-ish classes?

Started by
3 comments, last by pacman 20 years, 6 months ago
Crap, I just had this big long post, and the browser ate my submission. Anyway, ok...I have an Obj that is supposed to live it's life for a set time and then go away. I have an ObjMgr class that manages all the Objs, updating them and releasing them when they're dead. I guess the best way to describe my problem is with a small example: main () { init (); while (!done) { Obj ball (10); //ball that bounces on screen for 10 seconds, this call will work fine update (); //this is where ObjMgr updates } shutdown (); } //let's say this function gets called when a button is clicked void func () { Obj ball (5); //a ball bounces on screen for 5 s this gives me nothing } Ok my logic tells me that it gives me nothing because it's created, then the function ends, and the Obj falls out of scope and deletes itself. Not good. Is there a way I can make them stick around until they live out their lifespan without caring where they were called? If I change the call to: Obj* ball = new Obj (5); It works, but it's a memory leak. So that means everything is working, just that the Obj isn't static, but it can't be static, because I might want to press the button a few times and create different bouncing balls each time....Can anyone spare some advice? Thanks ------------------------------------------- The Lord will fight for you; you need only to be still. Exodus 14:14 [edited by - pacman on October 9, 2003 6:38:19 PM]
-------------------------------------------The Lord will fight for you; you need only to be still.Exodus 14:14
Advertisement
You need to do the Obj* ball = new Obj (5); if you want it to stay alive even after the call.

What I might suggest is that you also create the object using an interface in the objMgr something like objMgr.createBall(10); and then the objMgr keeps track of every ball that it has and deletes them when they die. That will eliminate your memory leak.

Or if the ObjMgr already has a reference to these objects (which it may have since its updating them apparently) it should just delete the object if the time is up for that object.

The main point is that your ObjMgr should somehow keep a list of all active objects and delete them when their time is up.
*sigh* ok, I just did some more testing, and I find that the call to delete the Obj is actually being called when I do the pointer way above....but I guess the memory isn''t really being released. So that means that my list.Delete isn''t acting right, so maybe someone can corret me on this?

The list is a standard doubly-linked list with a few tweaks, but basically it''s nodes with a data. When I delete a node, I basically do:
node* bye;
...
delete bye;
bye = NULL;

That has workded, but now since the data type is and not , maybe it''s not deleting what the Obj* is pointing to automatically? Is there a way I can check to see if the is a pointer so I can explicitly call "delete bye->data;"? Can anyone help this poor, confused man?

-------------------------------------------
The Lord will fight for you; you need only to be still.

Exodus 14:14
-------------------------------------------The Lord will fight for you; you need only to be still.Exodus 14:14
Hey Drek, thanks for your reply. Yeah, the manager has a list of type Obj* that it keeps track of, and basically it updates all of them. When the Obj.update is called, it ages itself, and if it's age runs out, it sets itself to alive = false;. Then the ObjMgr sees if that Obj is alive, and if it's not, it deletes the Obj. That part actually works, but it's not releasing the memory (see above). Any ideas?

-------------------------------------------
The Lord will fight for you; you need only to be still.

Exodus 14:14

[edited by - pacman on October 9, 2003 6:59:12 PM]
-------------------------------------------The Lord will fight for you; you need only to be still.Exodus 14:14
Why are you rolling your own list when the standard library provides std::list? You can also use Boost''s smart pointers and forget about deleting them yourself. http://boost.org for more details.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

This topic is closed to new replies.

Advertisement