From: "Johan Nilsson" <johan.nilsson@esrange.ssc.se>
"Andreas Huber" <ah2003@gmx.net> wrote in message
3. The entering/exiting of a state is modeled by the construction/destruction of a state object (see details in subsections).
3.1 Entering/exiting a state should be decoupled from
creating/destroying
the state objects themselves. I can see the simplicity in creating the states when they are entered etc, but for me states live continuously within a fsm; they are just entered/leaved at certain points in time.
So you would still have objects for states but you'd create them when the state machine is created, right?
No, before.
This is contrary to the scalabilty
requirements as a state machine would have to know exactly which states belong to it. I.e. you are forced to implement the whole state machine in a single translation unit.
No, only if statically defined. I was thinking in runtime-terms again, perhaps:
// // pseudo-code (no, I didn't think thoroughly before writing this) // from_state_id = fsm.add_state(<some-state>) to_state_id = fsm.add_state(<another-state>) fsm.add_transition(from_state_id, <on-event>, <event-result>, to_state_id) fsm.add_transition_to_self(from_state_id, <another-event>, <another-event-result>)
Could the fsm manage a container of (pointers to) state objects that it populates as it first creates each state object and from which it retrieves a state object when transitioning? IOW, the first time the fsm encounters the need to transition to a given state (from A to B, say), it creates B and tracks it in the container. Upon transition back to A, the fsm locates state A in the container and reuses it. With such an approach, the state objects are only created and destroyed once, and the fsm simply calls enter() and exit() member functions at the appropriate times. That means that states are added on demand, rather than all "up front," but once added, the fsm simply reuses them, avoiding free store machinations and overhead. BTW, not relying on a dtor as the "exit method" means that an exit transition can throw exceptions. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;