Re: [boost] [mixin] New library reminder

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

On 07/12/2013 09:03 PM, Klaim - Joël Lamotte wrote:
>   1. is the current version usable? I mean even with some bugs, are the main
> features usable already?

I think so. I don't plan on adding new features until the formal 
submission to Boost. I may work on the reflection part, but I'm not sure 
I'll have time for it.

We actually use the library in the company I work for a project that's 
under development, so the main features are actually used in production 
code and there don't seem to be any bugs.

>   2. did you avoid using a smart pointer in the introduction example for a
> specific reason? if not, I think it would be better to use one,
> just to avoid people copying this style of code.
>

Well I didn't want to overburden the reader with the notion of a smart 
pointer. The messages' first argument is `boost::mixin::object*` so 
using a smart pointer would also require the constant use of `ptr.get()` 
to call messages.

This makes me think, though. I'll have to think about making the first 
argument a reference to an object instead a pointer to an object, or 
allow both (with the cost of an additional copying of the actual arguments).

>   3. is there a way to go through all the instances of the same type? for
> example:
>     mutate(o)
>      .add<xml_serializer>()
>      .add<book_data>();
>
> Assuming there is more than one instance composed of book_data, is there a
> way to list
> or just apply a function to all currently instanciated book_data?
>
> If not, I think a way to do it would be useful in high performance cases
> (to update all the components of the
> same type in one pass, avoiding cache misses and enabling some possible
> concurrent update setup).
> But as it's not the core feature I think it would be a nice update.
>

The library doesn't provide such a feature. There are many axes by which 
the memory is accessed, so completely avoiding cache misses is 
impossible. Indeed, there are ways to improve on the cache locality on 
this or that axis, but that will be at the cost of worsening it on another.

Internally the object separately instantiates the mixins that comprise 
it and it effectively has a list of pointers to its mixins. If you 
mutate that object, removing or adding mixins, all of its other mixins, 
that are already instantiated, won't be touched. To keep all the mixins 
in a single buffer will require either dealing with big gaps and 
potentially badly fragmented memory, or moving the mixin data in the 
memory, which can be slow and WILL break any pointers that reference it 
(especially bad for classes that have self referencing in some way, 
like, say google::hash_map/hash_set).

A mixed approach CAN be introduced, but that will require the library 
users to have deep knowledge of its internal workings in order to choose 
how their mixins will behave, and that might alienate some users.

To deal with the problem of updating a huge list of objects of the same 
internal type (or memory problems in general) two things are introduced 
in the library:

* Object mutators - that speed up mutation by remembering what needs to 
be done and greatly improve on the performance of the naive 
`mutate(obj).add.add.add`
* Memory allocators that can be set for all mixin allocations or also 
for the allocations of specific mixins

Still it is the user's job to maintain lists of the objects by whatever 
criteria they choose (like object that have `book_data` in them). Sure, 
the library could easily store all kinds of lists by all kinds of 
criteria, but I fear that this will be memory wasted, since the users 
know best what and WHETHER to specifically maintain.

-- Borislav