David Abrahams wrote:
That's not exactly true. States are _types_ only at compile-time. At runtime, they are objects passed to correspondent call operator. Objects may be stateful.
struct Running { /* stateful */ }; struct Stopped { /* stateful */ };
Even more confusing; now you need a dynamic allocation to represent and change the current state of the machine. I suppose you could use variant, but I never understood why people want to put state _inside_ of states --
You very often encounter the situation that you need a variable that is only used in a part of a state machine (i.e. only one state or a few states need access to it). IMO, it is good design to confine the lifetime of such a variable so that it will not even exist when the machine does not happen to reside in the states that need access to the variable. Even for a very tiny state machine like the StopWatch in my tutorial it made sense to limit the lifetime of one variable. See http://tinyurl.com/5q9hk (State-local storage) for details.
it doesn't match up with the domain abstraction of state machines.
How do you come to that conclusion?
The state's identity should be enough.
It is sometimes enough for small simple machines but not almost never for large complex ones. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.