Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-05-28 17:51:50

"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

> Actually, the UML standard in one place ( hints in this
> direction but it is far from clear whether this assumption is
> covered by the UML standard (and could thus be put in the hard facts
> section).
> 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.


> I realize that the above reasoning is far from water-tight, as it is
> based qon two assumptions. However, I believe that most people
> proficient in the FSM domain will agree that it is safe to assume A1
> & A2.

I can't speak for them, but as I said, A1 seems far from obvious to

> 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.

> The above is the best reasoning I can currently give to show that
> failing exit actions do not make any sense. For me, this is more
> than enough to not ever consider them again (at least for an FSM
> library implemented in C++).

Well, I guess we're done then.

> I will answer questions arising from this post and I am interested
> in feedback whether this convinces people but I will not try to
> reason any further as I have run out of arguments and I think I have
> already invested too much time into this.

I know how you feel ;-)

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at