[boost] Re: Storing variables in states [was: Re: RE:Re: overloads-20050207.tar.gz]

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-02-15 17:56:47

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.