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-10 12:11:10

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

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

Best,
Vicente