Provide deleter callbacks for userData

[gilzoide]

More often than not, userData stored in worlds, bodies and shapes will be allocated on a per-object basis, requiring users to manually deallocate them for each object to avoid memory leaks.

For example, whenever I want to destroy a body, I need to iterate over all of its shapes, get each userData and delete them manually. After that, I get the body's userData and manually delete it as well.

Of course this could be wrapped in a helper function, but it would be much nicer if users could provide a userData deleter callback that Box2D would call whenever those objects are about to be destroyed. Of course, we would need one more function pointer in each struct and probably a getter/setter function for the deleter itself as well.

[HughPH]

When using Box2D as a shared library you would need Box2D to both allocate and free the userData memory, or you'll get an access violation or segfault. In this context Box2D cannot free the pointer, and it would need to store a flag to know that it was the origin of the pointer. It's also up to you how you allocate and free the userData for your usecase. It could live longer than the body, or shorter (you can swap it for another object anytime with b2Body_SetUserData, or use the pointer to store a number, or set it to 0). I would suggest that allocating and freeing memory is not the responsibility of a physics engine, and adding the capability to Box2D unnecessarily adds complication and ambiguity. You should be keeping track of your Box2D bodies already, if you don't want the userData memory for longer than the body, then it's up to you to free it when you delete the body.

[gilzoide]

What I was suggesting was that Box2D could call a user-defined callback for deleting userData memory, one with prototype void (*DeleteUserDataCallback)(void *userData). I agree it doesn't make sense for Box2D to neither allocate nor directly free the user data, but it could have a hook for userData deletion. When I allocate my user data, one instance for each body / shape that will live exactly as much as the physics object will, it feels like the body / shape could be the owner of such data and be responsible for deleting it.

[erincatto]

Part of the design goal of v3 has been to remove as many callbacks as possible. Every callback creates a new failure point. For example, Box2D could callback when a body is being destroyed and the user can destroy all the shapes on the body, leaving the body destroy function with some potentially stale references.

My approach for v3 has been to only have callbacks when there is no other reasonable choice. Here are the current callbacks:

• multithreading task handler
• custom shape filter
• custom friction and restitution mixers
• contact pre-solve handler

Some things that were handled with callbacks in v2 are now handled with events, such as begin/end touch events. Events are safer and more efficient.

[gilzoide]

I get your points, that's totally valid.

I just feel that when I allocate user data, exactly one instance for each body / shape that will live exactly as much as the physics object will, it feels like the body / shape could be the owner of such data and be responsible for deleting it.
But that's fine, maybe I'm too focused on my own use case, where I do allocate one instance per physics object and have to destroy them later, and not seeing the bigger picture.

[erincatto]

In my projects I avoid doing extra allocations for user data. Instead I will store something like an entity id or a pointer to my game data associated with the body/shape. This removes lifetime concerns.