From: Andreas Huber <ah2003@gmx.net>
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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;