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?

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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-02-05 13:36:52

Le 04/02/2016 11:45, Kris a écrit :
> On Wed, Feb 3, 2016 at 9:59 PM, Vicente Botet [via Boost] <
> ml-node+s2283326n4683180h99_at_[hidden]> wrote:
>> A local transition
>> (
>> https://en.wikipedia.org/wiki/UML_state_machine#Local_versus_external_transitions)
>>
>> form an outer state to itself exists from the most inner state but don't
>> exit from the outer state. If in addition the local transition goes to a
>> history state the inner state in re-entered.
>>
> I have seen it, thanks. Yea, local transitions are not supported currently
> by msm-lite.
> Are they supported by MSM? I haven't seen support for it there too. Anyway,
> they are
> not hard to implement. Do you have any important use case for them?
I don't know what important would mean here. I use them in my daily work 
so that I ensure that I don't exit from a state (representing an 
activity) until the activity is finished. I use to use them with the 
history state, but there are other uses without.
The implementation is simple and they are part of UML2. I find this 
enough motivating.
>
>
>> An internal transition don't exits at all.
>>
>> I have no preference for the notation, but why not replace the + sign
>> with a ^
>>
>> src ^ event [guard] / action = src
>>
>> src ^ event [guard] / action = src(H)
>>
>>
> Well, I have just followed MSM approach and '+' was used there and I was
> fine with it.
> Is there any reason why '+' is wrong and it should be replaced with '^'
> instead?
You misunderstood me. + will represent external transitions,  while ^ 
could represent local transitions.
>> With
>>> action_nexstate approach
>>> you have to check all actions to verify whether they are not changing
>> the
>>> state which might
>>> be tricky to do. Unless, you have a solution for that?
>> One possibility is to return the next-state.
>>
>> You could also restrict the possible next states in the table.
>>
>>         s0 + e / action_nextstate(s1, s2)
>>
> I implemented action_nextstate, so please take a look.
> It might be checked online HERE ->
> http://melpon.org/wandbox/permlink/IMZUWJpiHDP62WEO
>
> It's really easy to implement it, the basic idea below.
>
> auto action_nextstate = [](auto... s) {
>    std::tuple<decltype(s)...> states{s...};
>    return [=](msm::sm<auto>& sm, auto const& evt, bool external_value) {
>      action0();
>      if (some_guard1(external_value)) {
>        action1();
>        sm.change_state(std::get<0>(states));
>      } else {
>        action2(evt);
>        sm.change_state(std::get<1>(states));
>      }
>    };
> };
>
>
> I hope that helps.
I don't know. The syntax is horrible. I would like to be able to use the 
states themselves.

std::get<0>(states) doesn't scale.

Passing all the states each time to the action_nextstate will not be the more efficient way.
The states tuple are part of the lambda so the SM will store the tuple of states once for each transition. Even if this is not instantiated for each instance of the SM, this seems unnecessary.

I would suggest to have a single SM context that stores anything needed and let each transition have access to it.

> I do understand your concept, however I'm not sure
> whether such approach
> is the best, but, at least, it's easy to implement. I guess if you can
> prove that this is a common
> case and that performance might be gained using it then it's worth to
> consider such practice in general.
How many times you receive a message and depending on the message 
contents and the SM data context your SM will go to one state or another?
I don't know how I could prove that this is quite common, but I can 
ensure you that it is ;-)

For performances, there is already the space performances, there is no 
need to store local variable on the state machine context, and this can 
grow quickly.

For runtime, you avoid calling to process event on each transition 
segment, the code of a transition been in a single function the compiler 
can inline, optimize,  ...

Note that I'm not saying that MSM-lite should not support eUML2 transitions.

Vicente