David Abrahams wrote:
"Andreas Huber" <ah2003@gmx.net> writes:
Assumptions: A1. When a state machine object is destructed, the modeled state machine must also be terminated (i.e. the destructor of the state machine unconditionally terminates the state machine before returning to the client).
I've got a problem with that assumption. It seems to be an association made because of a conflation of C++'s notions of termination with the UML standard's use of the word "terminate" to denote something unrelated, at least as you described it in snipped text.
I suspected that we will disagree on this.
A2. If an exit action fails, the state associated with the exit action has not been left.
I'm fine with that assumption. In fact, that seems provable.
Yes, I realized that after posting. F1 provides strong arguments for A2.
Moreover, one could also question whether the UML standard should have any bearing for an FSM library that implements behavior that is not covered in the standard (i.e. exit action failures). I see failing exit actions as an addition or enhancement to the behavior defined in the standard. If such an enhancement breaks the behavior defined in the standard, I think the enhancement should be rejected.
Another thing I should mention: the finite state machine abstraction was around long before UML and will stay around long after UML has crumbled to dust because of its overbearing weight and its OO orthodoxy <wink>.
:-)
Actually I think that UML _state charts_ seem like a pretty good representation, but I'm not sure that I would want to read the UML spec like a bible when approaching the project of building a C++ state machine framework.
I'm reading it like a bible only when it helps to argue my case ;-). Otherwise boost::fsm takes many (hopefully undisputed) diversions from the UML standard (see http://tinyurl.com/33vht, UML to boost::fsm mapping summary). Regards, Andreas