On 07/13/2013 02:46 PM, Klaim - Joël Lamotte wrote:
To make to make it clearer: are allocators allowed to have a state, in your library?
Because it needs to know in which "world" pool to allocate. This assume that the different worlds are potentially not updated in the same thread or at the same time (which happen a lot in client/server systems). Also it allow updating only the world you want to update when it is acive, while keeping all the differnt worlds in memory - reducing efforts updates when the "player" in a game can be in only one world at a time. Basically, if I have to allocate, say, all the physics components in the same global array, then I'll have a hard time updating only those that correspond to a specific world, because if there is a lot of worlds and a lot of physics objects, I'll have to go through all of them just to update those of one world.
If I can set dynamically the allocator object, then that indeed solves all I mentionned.
The allocators in the library are classes of your own, that derive from a regular interface parent (class with pure virtual methods). They can have a state, and you can manage their instances. A piece of code like this is possible: // this has been set as the book_data allocator my_book_data_allocator.prepare_book_datas(objects.size()); for(o : objects) { o->add<book_data>(); }; To have all book_datas consecutive in memory, the need to move them within the buffer is needed (unless you allocate them ALL once and forget about them altogether). I could probably address this in some way. I'll have to think about it. I'll also think if I can do anything to make this easier for the user, but at a first glance, apart from documenting thoroughly how the mixin allocations work, I don't think I'll be able to help. You understand that if the user knows that their allocators provide memory that's to be used like this |object*...their own type|, they can safely manipulate the chunk in any way they wish. -- Borislav