|
Boost : |
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk