Boost logo

Boost :

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
* 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at