Re: [boost] [mixin] New library reminder

Subject: Re: [boost] [mixin] New library reminder
From: Borislav Stanimirov (b.stanimirov_at_[hidden])
Date: 2013-07-13 08:31:36

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