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