David Abrahams wrote: [snip]
Not in an innermost state, no. But you can simply store the variable in an outer state that contains all the states that need to access the variable.
Can't we call that thing "the state's associated data object?"
You mean the variable?
No, I mean the thing you're calling "the state."
That's pretty much agreed-upon terminology. The word "state" in the FSM field refers to two different things: 1. From <http://en.wikipedia.org/wiki/State_%28computer_science%29>: <quote>In information processing, a state is the complete set of properties (for example, its energy level, etc. see state (physics)) transmitted by an object to an observer via one or more channels. Any change in the nature or quantity of such properties in a state is detected by an observer and thus a transmission of information occurs.</quote> By this definition one would say that an FSM *has* a particular state. I assume that's the definition you use. 2. In state charts people call the boxes or circles (see e.g. <http://en.wikipedia.org/wiki/State_diagram#Mealy_machine>) also states. By this definition one would say that an FSM *is* *in* a particular state.
It's really the collection of data that is live when the machine is in a particular state.
Exactly.
The machine's state does _not_ correspond to the identity of that object.
Right.
Maybe it corresponds to that object's type.
... plus the auxilary data objects that are used/accessible when the machine is in that state.
Calling it "the state" gives me the willies.
Huh? I don't see where I have called the variable a state, so my assumption above must be wrong. I guess you lost me...
Let me know if you're still confused.
I hope not.
More often than not the outer state already exists for other reasons (e.g. reactions that all inner states have in common). E.g. in the StopWatch example, the Active state not only exists so that it can store the elapsedTime_ member but also because there is a self-transition that can be triggered when the machine is in either the Stopped or Running states.
Sorry, details please? Where is this example?
http://tinyurl.com/5q9hk (State-local storage)
So, it's a shorthand for writing the same transition to stop out of all of its substates.
Yes, or more verbosely, the self-transition on Active expresses that no matter in what inner state (Running or Stopped) the machine currently is, EvReset will always trigger an exit out of the currently active inner state and the Active state. After that the Active state is entered and then the Stopped state is entered (because it is the initial state inside Active).
Because I don't see how the data lifetime issues work out if you do that. Transitioning from INNER1 to INNER2 still causes all the data members of OUTER to be destroyed, because the INNER1/2 instances have distinct OUTER sub-objects.
I guess you could copy the relevant portion of the old state object by the means of giving each inner state a templated constructor (untested):
Copying data doesn't extend its lifetime; it makes a copy. It may be important not to destroy the original. Furthermore, the original may not be copyable.
Agreed. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.