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

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-25 13:32:07

From: Andreas Huber <ah2003_at_[hidden]>
> 
> > 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.
> 
> This is certainly possible. I just have my doubts whether this approach is so 
> much better speed-wise. If you customize state memory management, construction 
> and destruction doesn't take an awful amount of cycles. Searching that state 
> container might well take longer for large FSMs.

That's certainly an important consideration, but I was thinking
in terms of something built into the fsm framework, thus
providing the benefit for all clients versus requiring clients to
do work if they want the speed improvement.  If your concern
proves correct, then using the container approach isn't helpful.
However, the states' base class, which I presume is part of your
library, could provide a pool allocator for state objects.  That
would put the onus on the library, rather than the clients, and
would still reduce the (perceived, not proven) overhead caused by
creating and destroying state objects on each transition.

Don't forget, though, that part of my proposal was that state
objects would have enter() and exit() mfs rather than relying on
the ctor and dtor for entry and exit, respectively.  That can
simplify matters when dealing with exceptions.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;