Iain K. Hanson wrote:
What UML requires is not necessarily what is good for a generic FSM framework. The UML model is IMHO over complex and probably broken.
Yes, it is indeed broken (there is at least one contradiction in it). Whether it is overly complex or not depends on your application, i.e. how much abstraction you need/want to employ to implement the problem at hand. I have found that most of what is in there *can* be quite helpful.
An example is entry and exit actions for states. It is some what oxymoronic that a single state should actually consist of three sub-states because of entry and exit actions. The idea that they must be paired is particularly strange
Well, nobody forces you to pair them. My exit actions often don't do the exact opposite of my entry actions (e.g. see the StopWatch example). Sometimes I don't implement an exit action even if there is an entry action and vice versa.
as one of the most common uses of the concept in the networl protocol work that I am familar with is prior to entering the idle stae some initialisation work is necessary and prior to re-entering an idle state from an exit event we want to do some clean-up.
This whole concept is much better modeled *IMHO* by transitory states. These have the advantage that they do not have to be paired
You don't provide enough information for me to judge, but I agree that some stuff can only be implemented satisfactorily with transition actions (boost::fsm has them).
and they allow same/self-transition to be a no-op which is a very common requirement.
If you don't define entry/exit actions for a state without data members then a self-transition is essentially a no-op. If this doesn't convince you (e.g. because the state is still destructed and constructed once), you can implement this with an in-state reaction, which is a true no-op.
Classical FSM's are a mapping from state/event pairs to behaviour and transitions. The Idea that a state should maintain its own data and thereby become stateful also seems to be bad modeling and against the KISS principle.
Again, this depends on your application. You can find my arguments in the rationale (State-local storage, Speed versus Scalability tradeoffs). If this doesn't convince you then boost::fsm is not for you. I can't provide for everyone and I wouldn't be suprised to find more than one fsm framework in boost in say 5 years from now.
There are two other approaches to FSM's that do not apear to be discussed in the rationale; Herb Sutter, in an article hints at using boost::function for FSM's and the GOF state pattern tals of using singleton, flyweight states
Both of these approaches fail to meet so many of my requirements that I decided not to discuss them.
which are re-enterant and therefore offer exelent MT performance.
As I argue in the rationale, if you have FSMs residing in threads then the thread switching and locking overhead is typically much larger than the overhead introduced by boost::fsm. I measured on Windows and other OSes might be better in this regard but I still believe that the general rule applies. Regards, Andreas