Support for user allocator about joltphysics HOT 7 CLOSED

Merged #183.

from joltphysics.

Would like to see this as well. Might mean that you'd need to get rid of using std::vector and use a custom array class.

from joltphysics.

I was planning on using the allocator class that you can provide to std::vector, maybe I'll create my own container classes at some point in the future (for now it is not really in the way as it is mostly used for long term storage).

from joltphysics.

I have a problem that might be related to this (not sure). I have my own custom allocator where I keep track of memory, but when I am shutting down the app, I got tons of memory leaks from the memory allocated during the call to JPH::RegisterTypes();
Would be nice to be able to have a certain level of control over when I do want to deallocate that memory.

from joltphysics.

Can you try #146 and call JPH::Factory::sInstance.Clear()? My guess is that your leak detection code runs before the static destructors are called. I'm not 100% sure that this will fix it as some STL implementations seem to allocate memory even if the map is empty.

from joltphysics.

I did some more work on #146 and removed most of the memory allocated by global constructors and made the application responsible for newing/destroying the factory. There are a couple of allocations left by the global constructors, most notably the SphereShape used by Body::sFixedToWorld, but I believe that that should not be an issue for your particular case.

from joltphysics.

YAY!

from joltphysics.