[boost] Re: [prereview request][fsm]

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-06-01 02:18:15

"Andreas Huber" <ah2003_at_[hidden]> wrote in message
news:c9anfn$q40$1_at_sea.gmane.org...
> Johan Nilsson wrote:
> > Ideally a state should be state-less, right? Once created it should
> > always
> > be able to execute the same actions no matter when in time.
>
> No, even a state in its simplest form is not state-less (what an insight
> ;-)). Seriously, you for example could implement a single state with one
bit
> (there are better ways to do this but lets leave them aside for the
moment).
> The bit is set when the state is entered and reset when it is exited. What
> boost::fsm does is give you a way to augment this one bit with further
> information (again, see the StopWatch example). This design evolved
because
> it is almost always uneconomical and often downright stupid to implement
> everything with states. E.g. you might need to produce a reaction when the
> nth event arrives and just ignore the n-1 events before it. You can
> implement this without any counters or other data members just by chaining
n
> states in a row and connecting them with a transition triggered by the
said
> event. I think nobody in their right mind does this for n>2. So you use an
> in-state reaction that increments a counter, which you will need to store
> somewhere. I think it is best to store said counter in the state itself,
> augmenting the state information. For further arguments in favor of state
> local storage please see the rationale (State local storage).

I was not seriously considering this for a real-world implementation. If so;
why would I be in favour of long-lived state objects?

// Johan