Boost logo

Boost :

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

"Andreas Huber" <ah2003_at_[hidden]> wrote in message
> 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
> (there are better ways to do this but lets leave them aside for the
> 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
> 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
> states in a row and connecting them with a transition triggered by the
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at