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