Darryl Green wrote:
>  A state is considered left (and hence is destructed) only after exit
>  and transition actions have run.
> 
>  That is, the previous state is destructed immediately before the new
>  state is constructed. For nested states, all exit actions would run,
>  followed by the transition action, followed by destruction of the
>  states being left, followed by construction of the new state(s).
> 
> > I don't see what that would buy you.
> 
>  Well it buys access to the state being left from the transition
>  action for a start.

Right, but I don't think it is justified to complicate the interface and the
implementation (we'd need to add entry()/exit()) for that. As I've explained
in my answer to your other post you can always move such a variables into an
outer context that exists during a transition.

>  In addition, if the exit action isn't the
>  destructor, and it fails, you are still in the original state. A
>  state specific recovery action is possible, using the state's own
>  context. The state destructor still must not fail.

A state-specific recovery function would make error handling much more
difficult, as you have no idea what you need to do to bring the state
machine back into a stable state. If you e.g. make a transition from such a
state, it is not guaranteed that the machine is stable afterwards (see
Exception handling in the tutorial).

>  My specific concern is the use of the extended functionality to
>  produce states which have/build significant context that (should)
>  only exist until a transition action deals with it. I don't see that
>  using this state context after the exit action has run is a problem.
>  The exit action may well have added to or modified it to make the
>  context complete, not damaged (and in particular not destructed) it.

That's true, see above.

>  I'm also concerned that the current fsm destruction/exit action
>  implementation model results in an environment where I should avoid
>  using exit actions that have any significant external effects because
>  I don't want/expect them to be run when/if the fsm is destructed.

Concern noted. This is actually the central disagreement between me and Dave
Abrahams. If you have any real-world examples, I'd be *very* interested to
see them.

>  Both the above concerns can be addressed by using custom reactions to
>  implement "pre-exit" actions when/if this turns out to be necessary.

Yes. It becomes a bit cumbersome when you have multiple transitions
originating at the state though.

>  I'll have to use the fsm library some more to see if this turns out
>  to be the case regularly enough to make it a significant use case.
> 
>  So, I now believe that the library has the necessary flexibility, and
>  only experience will tell how much and in what direction that
>  flexibility gets used/stretched. I'll keep you posted...

Please do!

Regards,

Andreas


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost