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


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