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.