"Andreas Huber" <ah2003@gmx.net> wrote in message news:c9321i$njh$1@sea.gmane.org...
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.
This was exactly the same impression I've had all the time - somewhat analogous to COM+ where objects have no own 'state' and are constantly recreated or even reused, IIRC.
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.
This should really be more clearly stated in the docs - perhaps even the wording 'scalability' should be changed. You're referring to minimizing compile-time dependencies, right? 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)
The term "state local storage" feels a bit misleading to me - is that a well-known term? I relate to thread local storage, which makes me think that each state has some private storage accessible to only itself (well ok, maybe it has - 'this'). Is another wording possible?
- custom_reactions
Whether or not states are also destructed when they are exited does not make a difference here.
If that is the case; would it be possible to address the question by adding a state_lifetime policy to e.g. the state_machine class? // Johan