|
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-10 05:51:42
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.
>>
>> 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.
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. One doesn't
have to deal with undefined states .
Just for the record, Boost.MSM has a policy to set when change state should
happen.
>
> 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
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk