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@wanadoo.fr> 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@n4.nabble.com> wrote:
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
Le 08/02/2016 20:32, Kris a écrit : 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_sequenc...
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