Re: [boost] Re: FSM library question

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-02-26 20:50:02

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