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
> 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
for(o : objects)
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk