David Abrahams wrote:
on Mon Aug 11 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
- States are not an enum values but classes that may have a common virtual base, which allows to have state-specific and shared data in the FSM. The events are processed in states. I'm not sure that isn't overkill. In our implementation you are free to add any data you like to the FSM and use it in your transition (member) functions. Your approach doesn't allow to separate state-specific data from the common data. Yes, but in your approach the common data can't persist across state transitions. Is that not a serious limitation? Why? It does persist as long as the FSM persists. All states and their base classes are constructed and destroyed with the FSM and never in the middle.
I'm confused. If states 1 and 2 have associated data of types A and B, the fact that A and B are both derived from C does not mean that there is only one copy of the base class... or are you doing something special to have states 1 and 2 share a single object of type D derived from A and B?
That's right, the library constructs a composite class that derives from all states. This allows states to virtually derive from a common base and share its data between each other. This composite class is a part of the complete FSM, so all states live as long as the FSM does. Switching between states only calls enter/leave handlers in the states, which can be used to initialize or clean the data in the state.
[Please keep in mind that I'm not trying to say that the Book's FSM is better than the one in your library. It's clearly more limited.]
Yes, I understand that it's merely an example for the book.