[boost] Re: [OBORONA-SPAM] RE: Re: overloads-20050207.tar.gz

From: David Abrahams (dave_at_[hidden])
Date: 2005-02-13 15:56:01

"Andreas Huber" <ahd6974-spamgroupstrap_at_[hidden]> writes:

> 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.

But as I pointed out and -- you seem to agree -- that variable must
often persist through several states to which it applies.  In that
case, if you want the lifetime to change based on those states, you
can't store the variable in the state object.  boost::optional in the
state machine itself is the proper generalization of the idea.

>> it doesn't match up with the domain abstraction of state
>> machines.
>
> How do you come to that conclusion?

I have never seen a formal description of the FSM abstraction that
described states as carrying additional data inside them.  Have you?

>> The state's identity should be enough.
>
> It is sometimes enough for small simple machines but not almost never 
> for large complex ones.

I believe that auxilliary data is sometimes needed, but I don't
believe it's ever needed *in the state*.  A framework that managed
auxilliary state data might accept a a structure like this:

   mpl::vector<
       // speed applies to the "running" state
       aux_data<&player::speed, running>

       // title applies to the "stopped" and "paused" states
     , aux_data<&player::title, stopped, paused>
   >

where speed and title are boost::optional objects that are
automatically cleared by the state machine framework upon leaving the
states listed with them.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com