Boost logo

Boost :

From: David Cattarin (ditto_at_[hidden])
Date: 2002-09-08 13:52:01


Andreas Huber wrote:

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

I'll explain more below.

[snip]

>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?
>
>
>

My framework currently is being used by 6 others and they seem to like
it. :)

Anyway, there's not a chance I could combine all 20 state machines. We
have 20 state machines because it makes solving the problem
(interworking of network call protocols) more easy. An attempt to
combine them would result in a terrible state explosion. As it is, I
have about 60 states, with around 100 transitions, and about 150 events.
And we've only modelled the portion of the system we wish to handle. In
the future, we might have to handle as many as 300 events.

Yes, my system is type safe, but I don't define individual types for
each event, transition, and state. Events are a simple class with a
string identifier and a property map to contain the parameters. It is
simple, easy, and doesn't use much memory.

BTW, what is gained by typing each event? If your events are generated
interanally--mine are not--then you can catch, at compile-time, bad
events. I get messages from the network which are filtered in order to
determine the kind of event. A simple string identifier seems sufficient
to me.

Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk