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. ##########################################################################