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?

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@n4.nabble.com> wrote:

...

A local transition ( https://en.wikipedia.org/wiki/UML_state_machine#Local_versus_external_transi...)

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.

...

...

action_nexstate approach you have to check all actions to verify whether they are not changing

With 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 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