From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-26 16:26:19
Rob Stewart wrote:
> Andreas made the remark that tying construction to entry and
> destruction to exit helps with scalability. I imagine that means
> the he's worried about a potentially large number of states in
> some fsm's and that keeping all the state objects alive
> simultaneously could be a bad idea.
Ok, I guess I didn't express this clearly enough. When I mention scalability
I always refer to the fact that you can spread a state machine over multiple
translation units and that a change in one of these TUs will not trigger a
recompilation of the whole state machine. The two corner stones that enable
- State local storage. Every FSM object owns separate state objects. I.e.
state objects are *not* shared between multiple FSM objects (as they are in
some FSM implementations)
Whether or not states are also destructed when they are exited does not make
a difference here.
> If that's accurate, my
> question is whether this concern is valid. How many state
> machines have so many states that are so large that they would
> cause appreciable memory problems were the state objects not
> destroyed upon exit? I have no idea, and I won't speculate.
In some very constrained environments this might rarely be a valid concern
but I'd be surprised if someone chose to use boost::fsm in such a situation.
Don't get me wrong, I think it should still perform reasonably even on quite
constrained systems but for a few applications it will inevitably be too
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk