Re: [boost] Re: Finite state machine requirements

From: David Cattarin (ditto_at_[hidden])
Date: 2002-09-06 08:48:49

Hi,

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.

Thoughts?
Dave

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!
 >
 > Aleksey
 > _______________________________________________
 > Unsubscribe & other changes:
 > http://lists.boost.org/mailman/listinfo.cgi/boost
 >