[boost] Re: Re: Finite state machine requirements

From: Andreas Huber (spam2002_at_[hidden])
Date: 2002-09-08 12:06:06

Dave,

> As you can see, I agree with most of Andres's requirements. As a useful
> note, requirements should not mandate a particular implementation.

I agree. My proposal is just _one_ way to satisfy the requirements and a
very experimental one at that.

> Restrictions, however, are a different story. During the design of my
> framework, I placed the following restrictions on my implementation: A)
> dynamic_cast is verboten; B) object construction/destruction must be
> minimized; C) memory footprint must be kept as small as possible. These
> restrictions are all related to performance.

Is your framework fully type-safe, especially with events carrying
parameters? If yes, how do you do that without dynamic_cast?

> When you only have one state machine in an application, event delivery
> is easy. Two different state machines only slightly complicate the
> situation. With twenty different state machines, you have to use a
> factory to instantiate you state machines and you need to use an event
> dispatcher. For simplicity, the client should only deal with generic
> objects; after all, once you have an event, all you want to do is
> transition. Right? So, from the client point-of-view, it makes no
> difference what kind of state machine is being used (as long as it is
> the right one). If transitioning, or in other words, iterating over a
> state machine is all you want to do, then the factory need only return
> an iterator to the correct state machine. So, you can construct one
> (stateless) state machine that all the iterators iterate over. ;)

I've come across the
"there-are-3-state-machines,-to-which-one-should-I-post-my-event???" problem
in our project as well. Almost invariably such problems were solved by
_combining_ the state machines in question into _one_ state machine (there
were 3 machines because the work was spread over several people). This is
one reason why I think that an FSM framework should allow for more than one
programmer working on the same machine. Out of curiosity: Performance
problems aside, could you have combined your 20 machines into a single one
as well?

Regards,

Andreas