RE: [boost] Re: Finite state machine requirements

From: Iain K.Hanson (iain.hanson_at_[hidden])
Date: 2002-09-11 13:30:31

> [mailto:boost-bounces_at_[hidden]]On Behalf Of Andreas Huber
> Sent: 05 September 2002 23:02

> The lack of interest for my proposal here at boost made me
> think more about
> your approach to FSMs. Maybe everyone thinks a boost FSM should be
> dynamically configurable? Or maybe I just overestimated the
> utility of state
> machines in everyday programming (that's what boost libs are
> all about,
> aren't they)?

Dynamic fsm's and static ones are IMHO two very different beasts and I don't
believe that you can use a single framework to do both without violating the
C++ dictum that you don't pay for what you don't use.

BTW, there is a reasonable imnplementation of a dynamic FSM in the boost
files section IIRC.
These tend to be used much less than static FSMs because they have
additional complexity and for many maybe most applications, they do not need
to re-configure the state machine at run time.

[snip]

Regarding the proposal:

Hierarchical states and guards :- could these not be better modeled as
substates? IIRC I've
seen them used in Colored Petri Nets but not in normal applications where
states and
sub-states generally suffice.

Also, what are concurrent states? I'd be interested in a use case that used
both concurrent
states and hierarchical states with guards.

Of greater interest to general purpose applications would *I believe* be
something like aleksey's fsm. Particularly as it does not have the
dispatching overhead of your proposal.

Just my 2 pence worth.

/ikh