[SOLVED] Memory management, new and delete

Post Reply
Hieran_Del8
Posts: 11
Joined: Mon Nov 12, 2012 3:20 pm

[SOLVED] Memory management, new and delete

Post by Hieran_Del8 »

Where can I find information about memory management, and keeping references for bullet?

In looking through the box2d demo in the SDK, I noticed that several objects were deleted by accessing the world object, accessing the indexed collision shapes, then deleting associated motion states, and then deleting the rigid bodies. So is there a need to keep a reference of the motion data state, or even the rigid bodies outside of the world object? I notice that the collision shapes had to be maintained outside of the world object, and I understand there's some memory savings from reusing those created templates.

Also, sometimes new was called on one type of object (for example, "new btConvex2dShape") and delete was called on the same object, but when the pointer was cast to something else ("btCollisionShape"). I'm guessing that's a valid operation? I can't remember from studies with virtually overridden classes, but I was under the impression this operation caused a memory leak. The same goes for "btRigidBody" and "btCollisionShape".

Any "pointers" would be appreciated. :P Thanks!

EDIT 11/15/12:
This issue was resolved by the 4th post.
Last edited by Hieran_Del8 on Thu Nov 15, 2012 4:27 pm, edited 2 times in total.
Hieran_Del8
Posts: 11
Joined: Mon Nov 12, 2012 3:20 pm

Re: Memory management, new and delete

Post by Hieran_Del8 »

Hmm, well I answered one part, that delete accepts a void pointer, so the fact that delete was called on the object when it was cast to something else seems a moot point now (makes me wonder why that failed to work when programming directshow filters 4 years ago... :? )
khoowaikeong
Posts: 43
Joined: Fri Jun 15, 2012 7:11 am

Re: Memory management, new and delete

Post by khoowaikeong »

are we talking about the demo code or bullet itself?
the demo code does do some deletion but that is precisely because bullet itself does not delete these object.

however if implementing bullet on a new engine(which i am doing),
we do need to clean up the instances our object are using/generated...

---
I can't remember from studies with virtually overridden classes, but I was under the impression this operation caused a memory leak. The same goes for "btRigidBody" and "btCollisionShape".
if it a virtual classes with a virtual destructor, it should work. some compiler makes it a requirement that virtual class must have a virtual destructor...
MaxDZ8
Posts: 149
Joined: Fri Jun 24, 2011 8:53 am

Re: Memory management, new and delete

Post by MaxDZ8 »

Hieran_Del8 wrote:Where can I find information about memory management, and keeping references for bullet?
The rule is simple: if you new something, you must delete it.
Everything that is allocated in bullet is freed by bullet.
In other terms, you own resources you allocate.
That's it. It's in the manual.
Hieran_Del8 wrote: I noticed that several objects were deleted by accessing the world object, accessing the indexed collision shapes, then deleting associated motion states, and then deleting the rigid bodies. So is there a need to keep a reference of the motion data state, or even the rigid bodies outside of the world object?
Yes, because nobody will call delete on them.
Notice the demos are meant to be compact and easy to understand, not to to show proper management techniques. Motion states need to be kept somewhere as the app must be able to pull out transforms for rendering.
Hieran_Del8 wrote: I notice that the collision shapes had to be maintained outside of the world object, and I understand there's some memory savings from reusing those created templates.
Yes, that is correct. The shape is shared across all objects using it.
Hieran_Del8 wrote: Also, sometimes new was called on one type of object (for example, "new btConvex2dShape") and delete was called on the same object, but when the pointer was cast to something else ("btCollisionShape"). I'm guessing that's a valid operation?
I can't quite read this English so I'm guessing what you mean.
Calling delete on a btCollisionShape* or on a btConvex2dShape* is the same thing (for instances of btConvex2dShape) as btConvex2dShape is derived from btCollisionShape and btCollisionShape has a virtual destructor.
Hieran_Del8 wrote:I can't remember from studies with virtually overridden classes, but I was under the impression this operation caused a memory leak.
Yes, it could cause a memory leak and will potentially do so every time the dtor is not virtual.
Personally I would have made dtors virtual by default but there were quite some good reason to not do so in the past so I cannot really blame C++ for this.
Calling delete is perfectly safe if the dtor is virtual. And properly implemented as the correct function will get called anyway, regardless of the exact pointer type.
Hieran_Del8
Posts: 11
Joined: Mon Nov 12, 2012 3:20 pm

Re: Memory management, new and delete

Post by Hieran_Del8 »

khoowaikeong wrote:the demo code does do some deletion but that is precisely because bullet itself does not delete these object.
MaxDZ8 wrote:The rule is simple: if you new something, you must delete it.
Everything that is allocated in bullet is freed by bullet.
In other terms, you own resources you allocate.
That's it. It's in the manual.
Ah, thank you both for the clarification. When you start thinking in COM, it's befuddling to think otherwise again. :roll: For the record, I've read the manual through carefully twice now, and this particular issue isn't addressed. ;)
MaxDZ8 wrote:Yes, it could cause a memory leak and will potentially do so every time the dtor is not virtual.
Personally I would have made dtors virtual by default but there were quite some good reason to not do so in the past so I cannot really blame C++ for this.
Calling delete is perfectly safe if the dtor is virtual. And properly implemented as the correct function will get called anyway, regardless of the exact pointer type.
Thanks for the reply. I guess I haven't done these memory operations for a long time and got rusty. Thank you for the time and patience.
Post Reply