Boost logo

Boost :

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-29 03:16:12


David Abrahams wrote:
> "Andreas Huber" <ah2003_at_[hidden]> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk