On Sat, Jul 13, 2013 at 2:40 PM, Borislav Stanimirov
I now understand what you mean by two worlds. I'll think about what can be done in the library to accommodate for such a case. For now it won't be possible to separate the logic between two sets of objects.
My suggestion in the previous mail would be to allow to specify an allocator instance on boost::mixin::object construction. That would solve the problem immediately on the interface and semantic level, but I have no idea what impact it have on the library implementation.
The library provides something that's vaguely similar to this: domains. The domain is a set of mixins and messages that don't mix. You could add the same class and same messages to many domains and thus you'll be able to have your two worlds, but you won't be able to have N worlds, because you'll have to have the code
BOOST_DEFINE_MIXIN_IN_DOMAIN(**domain_a, some_mixin, features & a_allocator); BOOST_DEFINE_MIXIN_IN_DOMAIN(**domain_b, some_mixin, features & b_allocator); ...
But if the number of worlds is determined at runtime, this won't help you, plus managing will be a real nightmare with all the same internally generated names.
Yeah it's not useful at least in my use cases.
Still I think I'll be able to do something in this regard. I'll think about it.
Thanks! :) Joel Lamotte