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

On Wed, Feb 10, 2016 at 5:11 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 10/02/2016 11:51, Krzysztof Jusiak a écrit :
>
>> On Tue, Feb 9, 2016 at 11:00 PM, Vicente J. Botet Escriba <
>> vicente.botet_at_[hidden]> wrote:
>>
>> Le 09/02/2016 21:19, Kris a écrit :
>>>
>>> On Tue, Feb 9, 2016 at 5:13 PM, Vicente Botet [via Boost] <
>>>> ml-node+s2283326n4683364h3_at_[hidden]> wrote:
>>>>
>>>> Le 08/02/2016 20:32, Kris a écrit :
>>>>
>>>>> On Sat, Feb 6, 2016 at 10:34 PM, Vicente Botet [via Boost] <
>>>>>
>>>>>> [hidden email] <http://
>>>>>> /user/SendEmail.jtp?type=node&node=4683364&i=0>>
>>>>>>
>>>>>> wrote:
>>>>> I don't think you should correlate whether MSM manage exceptions and
>>>>> whether the configure function is noexcept.
>>>>>
>>>>>
>>>>> Why not? I find it better then being forced to setup some dummy type in
>>>>>
>>>> the
>>>> state machine to enable exception handling.
>>>> Please notice that exceptions handling is enabled by default (unless you
>>>> compile with -fno-exceptions). The only reason why
>>>> noexcept with configure when you create a transition table counts its
>>>> because it will give you more performance.
>>>>
>>>> Why do you want to loss this performance when you want exceptions
>>> enabled?
>>> Couldn't the configure function be always noexcept?
>>>
>>>
>>>> It's the opposite, I don't want to lose performance at any time.
>> Exceptions
>> handling cause a bit of overhead as you have to be in try { ... } catch
>> statement.
>> Well, C++ defines noexcept and that's a default, how would you like to
>> mark
>> that transition table can throw otherwise?. For example, noexcept(false)
>> seems a bit silly to use.
>> We don't have 'except' and therefore default behavior supports exceptions
>> unless you disable them via compiler flag.
>>
>> I understand that the try-catch would take time, and must be
> configurable. However I don't think that the noexcept qualification in the
> configure function is correct, as the configure function will throw or not
> independently on whether you have this try-catch, as it is related to the
> transition firing, not the transition table construction.
>

Yea, I do get your point but IMHO when you look at transition table
(make_transion_table) and you see that configure function is noexcept it's
quite easy to get what is going on, but again, it's just my opinion.
I tried different approach before, when I was checking all guards/actions
whether they are noexcept or not. The problem with this solution was that
lambdas expression are usually written without the noexcept
and, since the state machine was behaving the same, it was hard to notice
that performance went done. All in all, I just like the idea of using
facilities provided by the standard here. I know it's not exactly what
one may expect as configure will never throw or be/should called by the
user.

> When you say " When guard/action throws an exception State Machine
>>>>
>>>>> will stay in a current state.", do you mean that if there is an
>>>>>
>>>>> exception in the action part, the state will be the nesting state of
>>>>> the
>>>>> transition, as the exit of the source state will already be executed?
>>>>> If
>>>>> yes, this is not a leaf state, this is why I added a pseudo-state, to
>>>>> ensure a leaf state.
>>>>>
>>>>> It means that if exception won't be handled and that source state will
>>>>>
>>>> remains the current state.
>>>> Exit of the source state won't happen in such case too. Change the state
>>>> happens
>>>> after guards/actions were executed properly, otherwise source state is
>>>> still a current state.
>>>>
>>>> src_state + event [ guard ] / action = dst_state
>>>>                                                       ^
>>>>                                                       |
>>>>                                                     1. src_state +
>>>> on_exit
>>>>                                                     2. dst_state +
>>>> on_entry
>>>>
>>>> I believed that the order IN UML was
>>> 1 guard
>>> 2 src_state exit
>>> 3 action
>>> 4 dst_state entry
>>>
>>> 2,3,4 are executed only if the ward is true.
>>>
>>
>> I think UML doesn't specify the order when any of these should happen. At
>> least I'm not aware of it, but I might be wrong?
>>
>> Anyway, defining it the following way
>>
>> 1 guard
>> 2 action
>> 3 src_state exit
>> 4 change state
>> 5 dst_state entry
>>
>> may things much easier to handle from programming perspective.
>>
> It seems others disagree with your point of view as they have chosen exit
> before action :(
>
> I don't have a link to the UML recommendation, but the wiki agrees with my
> order.
>
>
> https://en.wikipedia.org/wiki/UML_state_machine#Transition_execution_sequence

Yea, it seems like. It's easier to handle exceptions this way, however,
being compliant with the UML is important.
I may change the order then as it will save me time in the future
explaining why it was done the other way ;)
Thanks for pointing that out.

>
>
> One doesn't
>> have to deal with undefined states .
>>
> Well, as I said before, you must consider that there is a TOP state
> associated to a SM. When you have a transition from S1 to S2, the action is
> executed in the context of the TOP state.
> I'm not saying that exit/action is better than action/exit, but if UML
> defines the order exit/action I will see why before changing the semantics.
>
> Just for the record, Boost.MSM has a policy to set when change state should
>> happen.
>>
> I wonder what was the rationale for this possibility. What
> Boost.Statechart does?
>

No idea what Statechart does. MSM rationale is here ->
http://www.boost.org/doc/libs/1_57_0/libs/msm/doc/HTML/ch03s05.html#d0e2714

BTW. I have a question related to local transitions. Concept seems to be
nice but I don't undesrtand why exit/entry is NOT triggered only 'if the
main target state is a substate of the main source'.
Why this concept can't be more general? Wouldn't that be nice?

s1 + e1 = s2 // exit from s1 / entry to s2
s1 ^ e1 = s2 // no exit from s1 / no entry to s2

> Best,
>
> Vicente
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>