Re: [boost] Re: [prereview request][fsm]

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-25 08:53:37

From: "Johan Nilsson" <johan.nilsson_at_[hidden]>
> "Andreas Huber" <ah2003_at_[hidden]> 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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;