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



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