[boost] Re: Re: FSM library question

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-02-27 19:41:51

Jeff Garland wrote:
> On Sun, 27 Feb 2005 11:40:52 +0000 (UTC), Darryl Green wrote
> 
>> When the obvious increase in code complexity is smaller than the
>> obvious decrease in code complexity?
>> 
>> I really need to ask - an obvious increase in complexity over what?
>> I have seen some truly complex code arise from *not* using an fsm
>> framework in some form or another.
> 
> The context of my comment was with respect to the stop watch example.
> I think we are all in agreement that the stop watch is too simple for
> the benefits of increased complexity required to use fsm.  And I'm
> thinking we might want to say something about that in the docs -- I'm
> afraid alot of developers would be scared away looking at the code. 
> A bunch of us understand that once the state machine gets a little
> more complicated the hand solutions tend to get ugly and buggy, but
> 
> 
> In particular I was thinking of some of the 'scary' code as:
> 
>  double ElapsedTime() const
>  {
>    return state_cast< const IElapsedTime & >().ElapsedTime();
>  }
>  //class running
>    virtual double ElapsedTime() const
>    {
>      return context< Active >().ElapsedTime() +
>        std::difftime( std::time( 0 ), startTime_ );
>    }
> 
> One part of the increased code complexity is just getting to
> understand the idioms to access other states.  The other part is that
> that originally threw 
> me was the locations of the time calculation functions.  It wasn't
> obvious to me why I would code the addition to elapsed time was in
> the destructor of the Running state versus somehow making it part of
> the running->stopped 
> transition.  In this case I was thinking about how I would explain
> the rules 
> of thumb to a 'junior' developer that actaully had to write the
> behavioral code. 
> BTW, I think part of my trouble might have been that the code
> context< Active 
>> is introduced before it is explained in the tutorial.  So I think I
>> got 
> distracted trying to understand what that code meant...

Ok, noted. I'll see how I can explain this better.

Regards,

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