Boost logo

Boost :

Subject: Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?
From: Kris (krzysztof_at_[hidden])
Date: 2016-02-03 10:26:25

On Mon, Feb 1, 2016 at 11:21 AM, Krzysztof Jusiak <krzysztof_at_[hidden]>

> Hi Christophe,
> Thank you very much for your feedback and time. I appreciate it a lot.
> Yea, I like having everything visible on the transition table and
> therefore I put initial states as well entry/exit actions there.
> I know you have a different view on that, however, I find it easier to
> follow this way.
> Declare events on the fly its easy to do, however, I don't think it will
> bring much value as events can be accessed outside
> the transition table as well as they, most likely, will hold some data.
> Therefore, I'm not sure about it. Might be useful to have
> both options tho.
> I would love to compare MSM-lite/MSM-eUML to eUML2, however I haven't seen
> it yet besides some code in the emails.
> Can you share a link to the eUML2 version, please? I will defo add
> benchmarks for it.

I added a simple benchmark using Boost.MSM3-eUML2 to the performance tests.
Results can be found here ->

It seems that Boost.MSM3-eUML2 (not sure what is the proper name?) compiles
2.5 times slower than the eUML, but maybe there are some flags/options to
speed it up?

Moreover, I'm not sure how to disable the slowing down options such as
deffered events etc.?
I would assume it should be as fast as eUML as it using the same back-end?

I have also noticed that the parser is not really strict as you can write
not valid code which will compiles. For example.
EUML2_ROW("Stopped + stop / stopped_again - Stopped"); // - instead
of ->

I don't see any problem with that as MSM-lite is open source. I also offer
> my help in designing and/or coding.
> Well, I would like to keep the core of the library as small as possible as
> in my experience a lot of users are actually not using
> as many features. Having said that, I have no problems adding new features
> via policies/extensions. Moreover, MSM-lite
> is already used in some of the top growing mobile games, but yea, I do
> agree that some users would like to see more features.
> Anyway, are there any specific features you are talking about which are so
> essential. I know that defer/history might be useful,
> but I don't see much more features in MSM, besides explicit/fork states?
> I totally admire MSM design. I really liked the separation between back
> and front end. I have even implemented some extensions
> myself:
> * dependency injection support (
> * testing support (
> And I also followed this approach in MSM-lite; it's not stated explicitly
> but it might be found there.
> Although it would be interesting to incorporate with MSM I'm afraid it's
> not possible with the current MSM as MSM-lite has a different approach.
> Especially back-end is achieved in a different way which is not compatible
> with MSM. While MSM-lite front-end
> still produces transitions-like types it holds objects and relay on
> dependencies to be injected. All in all, MSM-lite it's quite different
> than the current version of MSM. It maybe would be possible with a new
> version of MSM, however there is no such a thing yet, is it?
> Thank you again for your feedback!
> Cheers,
> Kris
> On Sun, Jan 31, 2016 at 9:18 PM, Christophe Henry-2 [via Boost] <
> ml-node+s2283326n4683114h53_at_[hidden]> wrote:
>> Hi Kris,
>> >I have recently released 1.0.0 version of experimental C++14
>> >Boost.MSM-lite.
>> >Your scalable C++14 header only eUML-like meta state machine library
>> with
>> >no dependencies, which outperform Boost.MSM - eUML in:
>> >- faster compilation times - up to 60x times faster!
>> >- smaller executable size - up to 15x smaller
>> >- slightly better performance
>> >- smaller memory usage
>> >- short error messages
>> I find it quite nice. The idea is very interesting. Minor nitpicks, I
>> find
>> weird mixing strings and <> syntax and the trick about inital states, but
>> it's really a matter of taste. It would also be good to avoid having to
>> declare events separately.
>> It would be interesting to see how it fares against the eUML successor,
>> eUML2 written using metaparse.
>> I do plan to rewrite parts of MSM and have a second look at eUML later
>> this
>> year, so if you don't mind, I might use some of your ideas.
>> I'm wondering where you want to go from there. Rewriting all of MSM is
>> quite
>> some work. But keeping the library lite is not really an option if you
>> want
>> more than a toy library because most potential users will want more
>> features.
>> Actually, the whole idea of dividing MSM in back and front ends was
>> exactly
>> to allow front-ends like yours as extensions. Would you be interested in
>> doing this instead? If changes in back-end are necessary, why not? It has
>> to
>> be done anyway, as most of the library was written 7-8 years ago.
>> It might mean that there will be a pre and post C++14 versions, but I
>> don't
>> think it matters.
>> Cheers,
>> Christophe
>> _______________________________________________
>> Unsubscribe & other changes:
>> ------------------------------
>> If you reply to this email, your message will be added to the discussion
>> below:
>> To unsubscribe from [MSM] Is there any interest in C++14 Boost.MSM-eUML
>> like library which compiles up to 60x quicker whilst being a slightly
>> faster too?, click here
>> <>
>> .
>> <>

View this message in context:
Sent from the Boost - Dev mailing list archive at

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