From: David Cattarin (ditto_at_[hidden])
Date: 2002-09-06 08:48:49
Andreas and I had part of a requirements discussion on
comp.lang.c++.moderated before he restarted the discussion here. I think
it might help if I repeat some of it here.
I've been building state machine frameworks for the past 10 years. My
current version (the 4th) has been used in production code for the past
2 years. It is part of a protocol translation framework for call
control. At times, there can be as many as 20 cooperating state machines
for a particular call. As you can guess, performance and memory
foot-print are important here.
During our discussions, I found that Andreas has a very different
approach that I currently use, though it is much like what I did in my
original version. In my approach, I've almost entirely discarded
inheritance from the framework. The only derivable classes are Action
and Guard. There are a lot of reasons, but based on my experience, I
have come to feel that state machines *and* state are just containers.
Now, I'm new to boost, but I have been learning about template
metaprograming for the past year. I have taken a quick look at the BGL
and think that it is a good mechanism for defining state machines. As
for States, I think it is just a class that holds entry Actions, body
Actions, and exit Actions. This allows me to reuse Actions in other
States will very little work. My Actions, are just functors. But I
really like the Functors as defined in Loki.
In my state machine framework, the majority of classes are stateless.
The only classes that do have state are the "iterator" that I use for
traversing the state machine and a special context object for holding
"user" state variables.
Unfortunately, I can't post my code. But I am very interested in seeing
what a boost version of a state machine framework would be. Again,
efficiency is very important to me. However, I don't believe that
creating individual derived types of each element in a state machine
will solve much. Based on the 80/20 rule, you'll find that most of the
work fixing a state machine is not spent on fixing transitions and the like.
Aleksey Gurtovoy wrote:
> On Thursday, September 5, 2002, at 10:02 PM, Andreas Huber wrote:
> > The lack of interest for my proposal here at boost made me
> > think more about your approach to FSMs.
> I don't think it's the lack of interest, more likely a lack of free
> time ;).
> I, for one, would love to see a generic FSM framework, along the
> lines of the requirements you've posted, here in Boost.
> > Maybe everyone thinks a boost FSM should be
> > dynamically configurable?
> I can't answer for everyone, but personally I happened to be interested
> in exactly the same sub-domain your proposal is dealing with, and I
> think I'll have something to contribute as well.
> Please keep working on it!
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk