On Sat, Jul 13, 2013 at 2:31 PM, Borislav Stanimirov <b.stanimirov@abv.bg>wrote:
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.
That solves the need to define myself how the components are allocated. yay. However I also want to be able to do something like: world.book_data_allocator.**prepare_book_datas(objects.**size()); objects.push_back( make_unique<object>( world.book_data_allocator ) ); // specify which instance of allocator to use for(o : objects) { o->add<book_data>(); }; I believe this adds a pointer to the allocator instance? 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.
Yes. Joel Lamotte