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
() ); // 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& 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
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