Memory Management and leaks

[xtreampb]

Ok so i'm trying to preform some memory management by deleting pointers to my object that have already been stored in arrays.

 

so like the code below

cBlock *_Block=new cBlock(true);
_Block->SetPosition(_Pos);
SetEntityCallback(_Block->GetFullModel(), (byte*)Coll, ENTITYCALLBACK_COLLISION);
CobbleVec.push_back(*_Block);
ObjVec.push_back(_Block);//must push back all blocks
//delete _Block;

 

i had to remove the delete _Block; line because i believe it is removing all the data completely (based on tests I've been running). I feel as though if I don't delete _Block it will result in a memory leak. As you can see i'm placing this in 2 different vectors. My question is how do I delete this pointer with out removing all references to my object. Is there like a copy command I don't know about?

 

Thanks

~Xtreampb~

[Josh]

You can use a pointer repeatedly and it doesn't make a copy of the object, so you don't have to delete it.

 

In Leadwerks 3, if you didn't know exactly when the different vectors would be done with the object, you would do something like this:

ObjVec.push_back(cBlock);
CobbleVec.push_back(cBlock);
cBlock->AddRef();

 

Then you would call Object::Release() when the object is removed from one of the vectors. Assuming you wanted the program to sort of manage the memory for you, and delete it when it was no longer in use.

[xtreampb]

so sort of like a built in memory management/garbage collector.

 

My current question is that i continously loop through the above code. when i'm done looping through do i need to do anything with this pointer. It is stored in the vector so my logic is to remove this pointer b/c i'm not using it. but like i said when i remove the pointer i call "delete _Block;" it removes the reference from my vector. So am i correct in saying when i delete a pointer in one place, it also deletes that pointer in another.

[Canardia]

You don't really need pointers when you use vectors. Just have a temporary scope object and populate it with different values before you push it into the vector. The vector takes a copy of it anyway.

[Josh]

so sort of like a built in memory management/garbage collector.

 

My current question is that i continously loop through the above code. when i'm done looping through do i need to do anything with this pointer. It is stored in the vector so my logic is to remove this pointer b/c i'm not using it. but like i said when i remove the pointer i call "delete _Block;" it removes the reference from my vector. So am i correct in saying when i delete a pointer in one place, it also deletes that pointer in another.

Yes. There is only one object.

[Pixel Perfect]

When you call delete on a pointer you are actually deleting the object the pointer is pointing to, not the pointer itself. The container will generate its own pointer which will point to the same object in memory when you use push_back. So if you delete the object both pointers will now point to an object that no longer exists. You can forget about pointers for all intents and purposes, they don't need explicitly deleting unlike the objects they point to

[xtreampb]

ok so would it be best to have a separate function (apart from the mObj::~mObj() function) that will delete the itself. when i want the object to removed because i'm done with it, I call this function. a separate question. After i'm done processing this object with outside object and functions. Can i remove it from my vector and have it manage itself. more specifically. once it collides, it shows a destroyed model. at this point i want to remove it from my vector and the object starts a timer. when the timer hits 5 secs it deletes itself. am i making sense, and if so, is this praticale?

[Pixel Perfect]

ok so would it be best to have a separate function (apart from the mObj::~mObj() function) that will delete the itself. when i want the object to removed because i'm done with it, I call this function.

I would say no. Simply call the delete function on the stored pointer when you wish to delete this object and lets its destructor take care of this.

 

After i'm done processing this object with outside object and functions. Can i remove it from my vector and have it manage itself. more specifically. once it collides, it shows a destroyed model. at this point i want to remove it from my vector and the object starts a timer. when the timer hits 5 secs it deletes itself. am i making sense, and if so, is this praticale?

You should retain the pointer to the object for as long as the object is still required. So assuming the continued existence of the model being rendered is dependent on the existence of the object (that is the object is responsible for the destruction of the model when the object is itself destroyed) the pointer should be retained until such point as you no longer require the objects existence.

 

If I understand your description, you have a model (possibly dynamic and animated) which is destroyed upon collision with some unspecified object/s. This model is then replaced with another model which represents the destroyed original. How you handle this very much depends on whether the new model has a separate existence as a class object in its own right, in which case the previous object could be destroyed at this point, or whether the same object invokes the model replacement in which case it would need to remain until such times as you no longer wish to display the destroyed model. I'm not sure if the 5 second timer you are referring to indicates that the destroyed models existence is planned to only be for 5 seconds and then disappears from the game?

 

Either way, so long as you retain the pointer to the object until it needs to be destroyed it makes little difference as to whether that is still in your vector collection or held elsewhere. As I don't know if your collection has any further purpose than just to maintain a list of existing game objects for subsequent destruction, or if it is used for calling update functions for instance every iteration of the game loop, I can't really comment on the need to remove it prior to the start of the timer or once it completes.