On Thu, Feb 11, 2016 at 12:28 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 10/02/2016 22:07, Krzysztof Jusiak a écrit :
On Wed, Feb 10, 2016 at 5:11 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
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:
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.
Yea, I do get your point but IMHO when you look at transition table
(make_transion_table) and you see that configure function is noexcept it's quite easy to get what is going on, but again, it's just my opinion. I tried different approach before, when I was checking all guards/actions whether they are noexcept or not. The problem with this solution was that lambdas expression are usually written without the noexcept and, since the state machine was behaving the same, it was hard to notice that performance went done. All in all, I just like the idea of using facilities provided by the standard here. I know it's not exactly what one may expect as configure will never throw or be/should called by the user.
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...
Yea, it seems like. It's easier to handle exceptions this way, however, being compliant with the UML is important. I may change the order then as it will save me time in the future explaining why it was done the other way ;) Thanks for pointing that out.
I will check it before. See below.
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?
No idea what Statechart does. MSM rationale is here ->
http://www.boost.org/doc/libs/1_57_0/libs/msm/doc/HTML/ch03s05.html#d0e2714
It seems that we need to inspect the UML2.1 documentation to check what is the specified behavior. If it is undefined, the argument in MSM would be valid.
I checked UML2.5 specification and I have found "Transition execution sequence" (14.2.3.9.6 / page 316). However, there is no much info about the sequence there. It's mostly about that exit of the main state has to happen before entry to the target state. I can't find anything about when guard/action should happen in the sequence :/ buy it's a long document so maybe it might be found somewhere?
BTW. I have a question related to local transitions. Concept seems to be
nice but I don't undesrtand why exit/entry is NOT triggered only 'if the main target state is a substate of the main source'. Why this concept can't be more general? Wouldn't that be nice?
s1 + e1 = s2 // exit from s1 / entry to s2 s1 ^ e1 = s2 // no exit from s1 / no entry to s2
A local transition will ensure that there is no exit on s1, but there should be an entry in s2 if s2 is not s1. You will need to have a nested examples to see the difference between an external and a local transition.
Yea, I do get it. Cheers. Do have any example when local transitions are useful? I see some usage for them but I struggle really to find a really good use case for them.
Vicente
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost