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