[snip]
What would happen if we wanted this to scale to more states, so that e.g. there's a State3 that we transition to in response to EvAnother? And so on with more states and events, where we'd like each of State3, State4, etc. to be implemented in their own dll. It would seem that we'd have to build up a hierarchy where we have one inheritance level for each state.
Not necessarily. It is usually enough when you enable client code to supply one or more *parts* of a state machine, each part containing as many or as few states as necessary. As I showed in the last post, you can use virtual functions whenever you want to transit to a state of such a client-supplied part and make those states visible to which client-supplied parts need to make transitions. I personally haven't used this very much, but it seems inheritance hierarchies should stay rather shallow this way. This approach sort of resembles the template method pattern. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.