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

For answers concerning entry()/exit(), please see my other followup to
Robert Bells post here: http://tinyurl.com/3583x.

>  Thinking about it there's (at least) one technical argument agains
>  mapping entry/exit to constructor/destructor calls - restrictions on
>  calling virtual member functions. Is this a 'hard' technical argument
>  of not ... depends on your point of view. For me personally the
>  semantics of explicit entry/exit methods is (at least) equally
>  important.

Adding virtual functions to a state class does not make a lot of sense
because you cannot derive from it (you'd be violating the requirement that
you must pass the most derived type to the simple_state<>  base class).

Regards,

Andreas


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