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 this are: - 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) - custom_reactions 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 slow/heavyweight. Regards, Andreas