From: "Johan Nilsson" <johan.nilsson@esrange.ssc.se>
"Rob Stewart" <stewart@sig.com> wrote in message
From: Andreas Huber <ah2003@gmx.net>
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.
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 used.
OK, I guess I launched off on a tangent. You make a good argument though that *if* state objects were only ever created once, then the initialization would only be needed once. The question arises, then, whether there are compelling cases where that's the case. For example, it would be possible to create a state class that referred to an external object for the reusable data, so Andreas' current design would only preclude you from putting that data in the state object itself. Thus, his current design can be made to fit your desires pretty easily, so it may argue against keeping the state objects alive. 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. If that's accurate, my question is whether this concern is valid. How many state machines have so many states that are so large that they would cause appreciable memory problems were the state objects not destroyed upon exit? I have no idea, and I won't speculate. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;