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

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


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