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: Krzysztof Jusiak (krzysztof_at_[hidden])
Date: 2016-02-02 16:12:30

On Tue, Feb 2, 2016 at 6:19 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 01/02/2016 11:57, Kris a écrit :
>> 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 don't see any problem with that as MSM-lite is open source. I also offer
>> my help in designing and/or coding.
> Hi, IIUC you are proposing a 3rd MSM library in Boost, and you don't
> pretend to make it a sub-library of Boost.MSM. If I'm right, I suggest you
> to rename the namespace to msm_lite or whatever you find more appropriated.

Fair point, thanks for pointing it out. It's a valid concern. I have
nothing against changing the namespace/name as 'msm-lite' is just a working
title either way. Not sure what the best name should be tho?

> BTW, with the figures you gave I believe that there would be an interest
> in your library.
>> 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?
> Well these are already quite a few features. I have not see local
> transitions (different from internal transitions).

Yea interna(local) transitions are supported. Example here ->

Please could you point me if you support choice points?

While choice points are unavoidable in graphical UML, I find it not very
> useful while writing MSM in C++ as I prefer to do it using if or switch.
> However having a transition table that can have only one next-state by
> transition disable this possibility. I use to have a transition table with
> a transition that has an action_nextstate that do the action and returns
> the nextstate of the transition.
> |"s2"_s + event<e2> [ guard ] / action_nextstate This avoids the storage
> of local variable on the MSM data context. |
> Have you considered this possibility?

Interesting idea, can you elaborate please as I'm not sure whether I follow
the idea with the action_nextstate?
If it comes to the choice points, I guess the easier way is just to have
multiple transitions from the same state?

    s1 -> s2 + e2 [some_guard1 && some_guard2] / action1
  , s1 -> s3 + e2 [other_guard] / action2
  , s1 + e2 / action3

would be the same as

if (e2) {
  if (some_guard1 && some_guard2) {
   } else if(other_guard) {
   } else {

> Best,
> Vicente

Thank you for you feedback.

Cheers, Kris

> 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
>>> <
>>> >
>>> .
>>> NAML
>>> <
>>> >
>> --
>> View this message in context:
>> Sent from the Boost - Dev mailing list archive at
>> _______________________________________________
>> Unsubscribe & other changes:
> _______________________________________________
> Unsubscribe & other changes:

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