From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-05-26 04:09:56
"Rob Stewart" <stewart_at_[hidden]> wrote in message
> 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
> > much better speed-wise. If you customize state memory management,
> > and destruction doesn't take an awful amount of cycles. Searching that
> > 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.
If you refer to my posts, I'd just like to make clear that I was never
concerned about overhead originating from the creation/destruction (to be
perfectly clear; memory allocation/freeing) of the state objects themselves.
I was more concerned about the execution of the code needed to initalize the
state objects, which is the same regardless of whatever allocators being
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk