[boost] Re: FSM library question

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-02-26 20:14:29

Hi Jeff

> I'm reviewing the FSM library and I'm wondering if there is any way
> for a transition to get a reference to the enclosing state machine.
> I couldn't see a way to do this in the docs.

This is explained right above the section heading "Getting state 
information out of the machine". Admittedly this might be a little hard 
to spot:

<quote>
Similar to when a derived class object accesses its base class portion, 
context<>() is used to gain access to the direct or indirect context of 
a state. This can either be a direct or indirect outer state (e.g. 
context< Active >()) or the state machine itself (context< StopWatch 
 >()).
</quote>

In addition, if you don't want to explicitly mention the StopWatch 
class, you can also use simple_state::outermost_context().

> The reason I'm think I would like to get a reference to the machine
> itself is that I can see an alternative design that might be
> 'simplier'.  Consider the following:
>
> using boost::posix_time;
>
> class StopWatch : fsm::state_machine< StopWatch, Active >
> {
> public:
>  StopWatch() : m_elapsed(0,0,0), m_last_started(not_a_date_time) {};
>  time_duration elapsed() const { return m_elapsed; }
> private:
>  //some sort of friend access that allows states to call these methods
>  friend StopwatchState;
>  void reset() { m_elapsed = time_duration(0,0,0) };
>  void start() { m_last_started = second_clock::local_time(); }
>  void stop()  { m_elapsed += second_clock::local_time() -
> m_last_started; }
>
>  time_duration m_elapsed;
>  ptime m_last_started;
> };
>
> The idea would be that the various transition constructors would

I guess you mean state constructors.

> simply dispatch back to the stop watch machine.  The structure of the
> machine would naturally prevent the calling of stop() before start()
> which would result in incorrect results (not_a_date_time -
> some_valid_time).  And it would also prevent other erroneous
> sequences such as start(); start(); step();
>
> Of course this will break the mapping to UML states and might be a
> bad idea,

I don't think this breaks any mapping to UML. Also, I don't think this 
is a bad idea at all. The functionality StopWatch implements is so 
simple that it can easily be implemented without the help of FSMs at 
all. So, the example kind of overuses the librarys' features to show the 
functionality. It's a classical "school example" (not sure whether one 
says this in English).

> but I'm just trying to explore exactly how the library can
> be used.  And maybe it would actually remove the need for the Active
> state.  Anyway, thoughts?

Of course you can easily get rid of Active, when you put the variables 
in the state_machine<> subtype, as you did.

> One small note, it would be nice if there was a second version of the
> UML diagram for the example that shows the transition details (that
> is, running exit updates active.elapsed) so that the code mapping was
> more obvious.

Ok, noted.

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.