[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.
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users
