From: Darryl Green (darryl.green_at_[hidden])
Date: 2004-08-30 20:37:10
Thomas Stevens <thomathoma69 <at> yahoo.com> writes:
> Andreas Huber <ah2003 <at> gmx.net> writes:
> > I very much believe that boost::fsm is suitable for many embedded
> > applications running in confined environments but there definitely
> > are applications for which the library is too heavy-weight.
> Ok, it is not just to drag in the boost::fsm then. I'll have to do a
> detailed analyze of the application and its enviroment.
Only you would know how detailed it needs to be. We did some initial
prototyping by writing one of the concurrent state machines our system uses
and testing it out. The generated code certainly isn't small, but it isn't
bloatware by modern (increasingly decadent) standards. It scales in a
predictable, basically linear way afaics, so it is reasonable to extrapolate
if you do some experiments.
The embedded environment I'm using boost::fsm in has some significant resource
constraints - similar RAM and CPU to a decent desktop PC of a decade ago. I
don't know how that compares to your case. The most "real-time" part of the
system uses boost::fsm and it isn't causing any dramas. That said, the hard
deadlines are around the 1s mark, though it has to handle 100s of events
inside that time.
We did try experiment with the earlier mpl example fsm (in mpl docs - I
haven't experimented with the code in Dave's posts) and while it worked it was
(understandably) much less comprehensive than Andreas's framework. Maybe an
mpl expert could produce an extended fsm that was genuinely lightweight, but
to be prefectly honest, while the mpl stuff is cool, I don't find the basic
example fsms a big advantage over the sort of table driven fsm implementations
that are common in C etc.
If all you really need is a very simple fsm, the alternatives to boost::fsm
are many. OTOH, it is relatively less likely that you have a performance
problem in the first place (but who knows - maybe you really need a fpga). If
you need more complex nested and concurrent state machines, boost::fsm is the
fastest way to assemble them I've seen. Other features, like the context
concept, may be seen as unncessary overhead or a really important and
efficient feature depending on your system design.
If what you want is a really lightweight fsm, use goto...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk