"Andreas Huber" <ah2003@gmx.net> wrote in message news:c9aid2$g3g$1@sea.gmane.org...
Robert Bell wrote:
Why else would you want to change the implementation (while leaving the interface as is)?
[...]
By using constructors and destructors for entry and exit, you're telling users that fsm guarantess that States will be constructed and destroyed at specific times, which means that for all time fsm must provide those guarantees.
Yes, what's so bad about that? We'd have to guarantee the same with entry() and exit().
It strikes me that making that guarantee with entry() and exit() may be easier to maintain if the implementation changes.
Only if I would see the slightest chance that such an implementation change will ever become necessary. To the contrary, entry() / exit() would inevitably complicate the implementation and I'm not convinced that it has any advantages whatsoever (performance or otherwise).
As you referred me to this posting in another part of this thread; I'll break in here: - You asked why calling virtual functions in the context of the constructor was necessary when the state must always be the most derived state: What about the case when the most derived state also derives from a protocol class? E.g. (rather contrived perhaps): struct x_proto { void do_x() { pre_x(); in_x(); post_x(); } private: virtual void pre_x() = 0; virtual void in_x() = 0; virtual void post_x() = 0; }; struct x : fsm::simple_state<x, ...>, x_proto { x() // aka 'entry' { x_proto::do_x(); // will probably work ok if we are fully constructed before this call, but doesn't 'feel right' } virtual void pre_x() { ...} virtual void in_x() { ... } virtual void post_x() { ... } }; - Is it possible to indicate that a state should exit right away in boost::fsm (I'm not sure what this would be referred to as in FSM terminology - a 'transitional state' perhaps)? E.g.: struct flush_buffers : fsm::simple_state<...> { flush_buffers() { ... flush ... ... if ok - goto xxx_state ... if fail - return to previous } }; This was just me trying to find some examples where the current design could be limiting. What might (or might not) be the problem is that constructors and destructors are special functions with special limitations and I'm not so sure that entry/exit of states should be limited by this. Perhaps this would change if the notion of a "state" in boost::fsm would change to a "state_activation" (ref Topher Cooper's post). Regards, // Johan