Hi @iboB, I'm a graphic designer and I like to collaborate with open source projects. Do you know that the graphic image of a project is very important? thinking about it I would like to design a logo for your Project Dynamix.

I will be pleased to collaborate with you.

The problem is basically this:

class a {
public:
    void foo(); 
};

class b : public a {};
    
decltype(&b::foo); // -> void (a::*)()

The caller in the message macros gets instantiated with as <Mixin, Ret, Ret (PARENT::&Method)(args)> and cannot be implicitly cast to <Mixin, Ret, Ret (Mixin::&Method)(args)> .

An explicit cast needs to be added in get_caller_for

I'm experimenting with your library and I like the design. But I've come across an error in my editor implementation and I'm not sure how to handle that.

Basically I have a basic object in which I can add mixins. And I have multicast messages for different purposes (showing gui stuff for example). Now when I create a new (empty) object and send a multicast message I get a "bad_message_call" exception because the object has no mixins in the initial state. Should I add a "default" mixin with empty implementations, is there something similar to default-implementation for multicast messages or should it be allowed to send multicast messages to empty objects?

In https://github.com/iboB/dynamix/commit/79677e95655a4e02fb6780be2bf5fa8b3ea59359 the bulk of the message call code was moved into variadic template classes and out of the macros. This allowed better debugging of messages as a step-in takes you directly into debuggable C++ code instead of a macro.

However there are user reports of 3-5 times slower builds with gcc and clang with this new feature.

(Curiously msvc 2013 and 2015 builds don't seem affected by this. 2017 hasn't been tested yet)

namespace foo
{
DEFINE_MIXIN(bar, ...);
}

With the current macros and no typeid this sets the name "bar" to the mixin. Previously it used to be "foo::bar". Not only does this break backwards compatibility but also, name clashes will ensue of different mixins in different namespaces with the same name.

Reverting to typeid seems like the only solution.

Calling a multicast with an argument by value calls the move constructor on the first call in the chain. This isn't a problem with simple types whose move constructors don't destroy the source but can cause bugs if the source is destroyed (with a vector for example)

Example repro:

DYNAMIX_MULTICAST_MESSAGE_1(void, testv, vector<int>, data);
 
class a
{
public:
    void testv(vector<int> data)
    {
        cout << "a: " << data.size() << endl;
    }
};
 
DYNAMIX_DEFINE_MIXIN(a, testv_msg);
 
class b
{
public:
    void testv(vector<int> data)
    {
        // vector is destroyed here
        cout << "b: " << data.size() << endl;
    }
};
 
DYNAMIX_DEFINE_MIXIN(b, testv_msg);
 
 
int main()
{
    auto hero = new dynamix::object;
    dynamix::mutate(hero)
        .add<a>()
        .add<b>();
 
    vector<int> foo = {1, 2, 3};
    testv(hero, foo);
 
    return 0;
}
 
DYNAMIX_DEFINE_MESSAGE(testv);

If a message is unregistered (ie no mixin implements it, and it doesn't have a default implementation) a crash occurs when it's called for an object. Instead bad_message_call should be thrown.

Very nice library! As i can see the usual behaviour for calling a message to a mixin that does not implement it is throwing an exception, wich is nice.

As an alternative i can define DYNAMIX_NO_MSG_THROW

to trigger assertions instead.

What about an option to simply doing nothing in the case the message is not implemented?

That could be compilation unit defined or mixin defined or "interface" defined.

That would be helpful in calling a message for each element of a vector of objects of wich only some implements a certain interface.

(Try-catching would be time wasteful)

Due to an old (and dropped) requirement to allow the same mixin to be instantiated multiple times from static libraries in many places of the code even though an instance of mixin_type_info is available, it is still obtained from the domain by using the id only. This is a needless indirection now and can be removed.

Using type info is a convenient way to get mixin names, but it has its limitations. For a small price on feature parsing / registration (all at global scope) we could ditch the type info requirement and remove the limitations associated with it (when using type info mixins must be classes and never structs) by getting the mixin name from the definition macro.

Executables which have plugins, report leaks at exit. They are suppressed for now, since it's not obvious what causes them and they are small, and seem insignificant. The most likely culprit is the lack of proper shutdown of plugins (for which we can do nothing). However an investigation for what causes them is needed in case we can do something.

It is time for v2.0 to address deficiencies in the current design.

Concrete things:

• Use C++17 this is a long way into the future, so why not...
• #24
• #25
• #26
• Better header structure
• Improve design of public and private data for objects (no more #define internal public)
• Mixin/Message domains – sets of mixins and messages that cannot be mixed. Will throw a runtime error when trying to combine certain mixins or messages.
• Address serialization better
• Allocator extension
• Mixin class which holds information for mixin
• Get implementers for msg as mixin ids
• Allocators for absolutely everything
• Allow onMutated private message
• Compilation performance benchmarks
• Logging and debug information prints
• fuzzing
• Package managers and cmake install
• coverage
• Optimize mutation process: less allocations. Design special mixin_collection for the process, that can be preallocated (or that uses a buffer that's allocated only once) and has reserve. Allow reuse of single_object_mutator.
• Add a new mixin feature fact. Facts are static const variables in a mixin. No multicasts. No virtual tables.
• Reflection. Call messages by string.

object_type_info in a system with many messages (4096) and mixins (1024) can reach 200 KB per instance. With many mutations the types can reach hundreds which ends-up taking tens of megabytes.

Investigate ways to make the memory footprint smaller.

Also garbage collecting unused type infos.