"Andreas Huber" <ah2003@[...].net>  wrote in message
news:c9anfn$q40$1@[...]..
>  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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost