"Andreas Huber" <ah2003@[...].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.

>  Actually, the UML standard in one place (2.12.4.4) 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.

<snip> 

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

>  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
http://www.boost-consulting.com

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