From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-29 03:16:12
David Abrahams wrote:
> "Andreas Huber" <ah2003_at_[hidden]> writes:
>> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk