"Andreas Huber" <ah2003@[...].net>  writes:

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

I know there's a smiley, but you're not doing your credibility any
favors with that statement.  It makes me wonder how many other
decisions in the design have such a flimsy foundation.

If you want to convince _me_ (I'm not saying that's important or
anything), you're going to have to make the case for why an FSM object
should make transitions (or state changes, if you like) when it is
destroyed.  To me it seems like there are very obvious use cases
supporting the argument that it should *not* happen.  Furthermore, it
seems as though, if you want that behavior, it's trivial to get it by
wrapping the FSM in a derived class whose destructor finalizes the
state machine.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

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