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@n4.nabble.com> 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
On Tue, Feb 9, 2016 at 11:00 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote: 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
<http://boost-experimental.github.io/msm-lite/user_guide/index.html##sm-state... ">
http://boost-experimental.github.io/msm-lite/user_guide/index.html##sm-state...
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