David Abrahams wrote:
Even an ad-hoc state machine implementation should have some type of "tick" or "clock" type method that takes a token or message (with or without payload).
I can't picture what you have in mind here.
What Phil described tracks state just fine; however, I wouldn't call it a *machine*. State machines consist of states and transitions. Transitions are transversed upon some stimulus. The *machine* part of the state machine receives the stimulus and then causes the transition to a new state. It is not uncommon to call the stimulus a token or a message consisting of the stimulus and data. Often the state machine "method" operating on the stimulus is called a tick or clock. What was described allows the user to take any transition at any time by invoking a method which then stores the new state. It lacks a concept of stimulus causing a transition.
So, while your ad-hoc machine will track a state if the methods are called in a valid order, I'm not sure I would refer to it as a state machine.
I would. It's certainly no less valid than the one presented in C++TMP.
I apologize, I am not familiar with that presentation. State machines are not foreign to me. I commercially offer my own UML (Real-time Object Oriented Methodology ROOM) package that takes a graphical representation through code generation and targets many OS's or bare metal. I extensively use state machines in FPGA implementations. Perhaps I am missing something. Maybe we are not talking about event driven state machines? I am happy to be shown something else. Best Regards - Michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com