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-09 18:00:07

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?
>
>
>
>> When you say " When guard/action throws an exception State Machine
>> <<a href="
>> http://boost-experimental.github.io/msm-lite/user_guide/index.html##sm-state-machine
>> ">
>> http://boost-experimental.github.io/msm-lite/user_guide/index.html##sm-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.
>>> You can handle specific type of the exception(exception<type>) or just
>>> any(exception<>).
>> What would be the event associated to the action in this cases?
>>
>>
> Simply, none. It won't compile when you try to add action/guard with the
> event for this transition.
> In case of exception<>:
>
> auto guard = [] (auto event) {} // won't compile
> auto guard = [] () {} // okay
>
> However, you can get some info about the exception using
> std::current_exception
>
> auto action = [] () {
>      auto exptr = std::current_exception();
>      ...
> }
>
>
Yes this should work.

Vicente