Re: [boost] [mixin] New library reminder

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

On 07/13/2013 12:31 PM, Klaim - Joël Lamotte wrote:
>
>
>
> From  what I understand, the allocator might be enough to allow the user of
> the library to set up a pool or dynarray or non-ressizing vector of
> components of the same type,
> which would be the feature I'm asking for.
> I'm not sure though. Would it be problematic to allow the user to provide a
> factory function for the component on addition, so that there is a simple
> way to
> make sure the component is created the way we want?
>
> Something like:
>
>      mutate(o).add( [&]{ return world_components.create<book_data>() ); //
> template parametter types implicitely inferred
>      // the added data_book is allocated in an array (or stable vector or
> pool or...)
>      // here add would take a unique_pointer or similar - or maybe a second
> function for deletion - or maybe an object providing both, like an alocator
> but dynamic.
>

Unfortunately allowing the user to maintain their own pool of 
pre-created mixins is not possible (well it may be possible with some 
arrangements, but it's not likely that I'll address this in the near 
future). The main problem with this is the need for `bm_this`.

bm_this is a macro that gets you the object from which this mixins is a 
part of. In order for this to work the memory that's internally 
allocated for a mixin is `sizeof(object*)+sizeof(ActualMixinType)` bytes 
and then the constructor is called for the second piece of memory. 
Essentially bm_this expands to in the sense of 
`(object*)(this-Ptr_bytes)`. There is no other non-intrusive way to do this.

I do mean to address the constructor problem, though, but again, not 
soon. I will allow the users to choose which constructor is called for 
their mixins.

> Which then would allow something like:
>
> world_components.for_all<book_data>( [&]( book_data& data ){ data.update(
> info ); } ); // go through the array of book_data to update them all
>

I'm not sure what this is supposed to do. You could do something like

for(auto o : objects_with_book_data) // your own array
{
     o->get<book_data>()->update(info);
}

You could also have a message called update (handled by not necessarily 
only book_data) and code:

for(auto o : objects)
{
     update(o, info);
}

> What I fear is that the allocator would not be enough to allow different
> pool/list/whatever of these components to be defined,
> for different "contexts". I have a case where I need different "worlds" to
> exists in parallel and components are gathered in type-specific (stable)
> arrays.
>

The allocator works like this.

When an object is created or mutated it first allocates the array of 
mixin pointers for its mixins, then it allocates memory for each new 
mixin (plus object*) and arranges them in this array.

You're allowed to set a global allocator that takes care for all these 
allocations, and you're also allowed to assign specific allocators per 
mixin type. For example book_data_allocator, which will take care to 
allocate memory only for mixins of type book_data.

So if your programs often mutates a huge group of objects by adding and 
removing specific mixin to them it's a good idea to provide a specific 
allocator for that mixin type and pre-allocate the entire chunk memory.

As for your worlds example you could easily set the allocator to all 
rendering mixins to be A, and to all physics mixins to be B.

-- Borislav