RE: [boost] Re: ANN: review of FSM library starts

From: Simon Gittins (Simon.Gittins_at_[hidden])
Date: 2005-02-24 01:10:06

Hi Andreas

[snip guard discussion]

> 
> The equivalent with a custom reaction would look as follows:
> 
> struct StState : fsm::simple_state< StState, StOuter,
>   fsm::custom_reaction< EvEvent > >
> {
>   fsm::result react( const EvEvent & evt )
>   {
>     if ( cond )
>       return transit< StRes0 >( &StRes0ActCtxt::Action0,  evt );
>     else
>       return transit< StRes1 >( &StRes1ActCtxt::Action1,  evt );
>   }
> };
> 
> For a human, IMHO this is easier to read.

Easier, but less consistent.

In complicated fsms (many transitions, lots of state local data and
functions), I find it extremely useful to separate the 'state' (as it
would appear on a state chart) from the 'other stuff' (local variables,
local functions - anything looking like 'normal' c++).  Given that
guards tend to be fairly common in real world fsms, we should be able to
spot them in the same way we spot normal transitions.  

> 
> > I haven't thought about the implementation too much admittedly.
> > Having
> > this would be a big help in automatically generating UML state
charts.
> 
> Agreed. It is much easier to implement a tool that only needs to look
at
> the state declarations than one that additionally also needs to
analyze
> code inside functions. For this reason I think I will eventually add a
> construct similar to the one you suggested. But, since such a tool
does
> not yet exist (to my knowledge), this is of fairly low priority at the
> moment.
> 

OK.  My argument is largely philosophical.

> > The library produces large binaries.
> 
> The produced binaries certainly will never be small. Out of curiosity,
> do you have any numbers (number of states -> size of executable)?
> 

I just ran a few tests.  The original camera example compiles to 103k
using -O3 and -DNDEBUG (and the other options specified in the Makefile
in the distribution).  When stripped, the size came down to 56k.

I added a new nonsense state in Shooting.hpp:

struct Shooting2 : fsm::simple_state<Shooting2,Camera,
  fsm::transition<EvShutterRelease,NotShooting> >
{};

I also changed Shooting's EvShutterRelease to transition to the new
Shooting2 state.  The compile size increased to 111k, and the stripped
size increased to 61k.

In my application (as described below), I added a state with 9
transitions that was empty otherwise.  When compiled with -g and
stripped (our current 'release mode'), the size of the executable
increases by around 30k.

I didn't spend too much time on these tests, and I ran them with a
version of boost::fsm that is a few months old (my apologies).

> > It does however, appear to scale
> > reasonably well (anecdotally, it seems about linear with the number
of
> > states).  The in memory footprint is of the same order of magnitude
as
> > the binary size.
> 
> I guess that is for the hundreds of machine objects you mention below?

Yes.

The in memory size is not important for this application (we have far
more RAM than persistent storage).  

Regards
Simon Gittins

##########################################################################
This e-mail is for the use of the intended recipient(s) only.  If you have 
received this e-mail in error, please notify the sender immediately and 
then delete it.  If you are not the intended recipient, you must not use, 
disclose or distribute this e-mail without the author's prior permission.  
We have taken precautions to minimise the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any 
attachment to this message.  We cannot accept liability for any loss or 
damage caused by software viruses.

##########################################################################