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-05 15:58:28

On Fri, Feb 5, 2016 at 6:36 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> 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
>>> (
>>> )
>>> 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.
>> I do get your point now. It's a valid feature. I added a task to
investigate/implement local transitions. However, I can't promise when the
implementation will be done. Firstly, I have to finish the support for
defering events.

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

Yea, I do get it know. Thanks for explanations.

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

Fair do's, it ain't perfect. However, it doesn't have to be done this way.
I mean, states don't even have to be passed into action_nextState at all,
which makes the implemention clener and easier to follow.
So, the new version would look like that.

auto action_nextstate = [](msm::sm<auto>& sm, auto const& evt, bool
external_value) {
  if (some_guard1(external_value)) {
  } else {

and transition table

    return make_transition_table(
      *"idle"_s + "event"_t / action_nextstate
     , "s1"_s + "event"_t / [] { std::cout << "in s1" << std::endl; }
     , "s2"_s + "event"_t / [] { std::cout << "in s2" << std::endl; }

BTW. This version is achieved without any changes to the current version of
msm-lite because setting states is done via testing extension.

Working example here ->

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

I don't like 'God objects'. IMHO, it's way better to inject whatever is
required by guards/actions. It's easier to test and maintain it this way
and there is no need for a SM context in the action_nextState example.

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

Okay, I see your points. I guess usage of action_nextState might be
justified and might be easily implemented in msm-lite too.

> Vicente
> _______________________________________________
> Unsubscribe & other changes:

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