On Sun, 27 Feb 2005 02:14:29 +0100, Andreas Huber wrote
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>
Right thanks, I missed that....
In addition, if you don't want to explicitly mention the StopWatch class, you can also use simple_state::outermost_context().
Ok, good.
The idea would be that the various transition constructors would
I guess you mean state constructors.
Yes, right.
I don't think this breaks any mapping to UML. Also, I don't think
Hmmm, ok. I was thinking the mapping was 'mechanical'. States/Transitions map to bubbles / lines respectively, etc.
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.
Sure.
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).
Understood. Getting an example of the right level is extremely difficult and I think overall you've done an excellent job in the tutorial. Of course the interesting design question is, at one point does the obvious increase in code complexity make using the library 'worth using'? For this discussion I'm presuming that there is no automated code generation which obviously changes things. And, of course, there's no right answer to the question -- which is why I was exploring my implementation options to understand how the code complexity / mapping would change if the state was concentrated in a single class instead of distributed amoungst the states. So the other general design question is -- when is it better to but the variables asoociated with the machine in a state class versus pushing them up to the machine? Again there may be no answer here, but maybe someone that has implemented real code using fsm would have a design heuristic... Jeff