Simon Gittins <Simon.Gittins <at> maxgaming.com.au> writes: [snip code]
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.
Ok, I have added this to the to-do list.
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.
I did the same with MSVC and got no difference (both exes are 48KB). I guess this is due to padding to the next 4KB. One reason for the existence of the BitMachine example is to demonstrate executable sizes. With the current version I get the following sizes (all with the lib out of the box): # states, #transitions, executable size (KB) 2, 2, 32 4, 8, 29 8, 24, 52 16, 64, 72 32, 160, 128 So, it seems that 30 states and 158 transitions fit into 96KB
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.
Hmm, that's definitely more than I would have expected. Judging by the numbers above it seems that transitions do not have a huge effect, at least not with MSVC. However, the BitMachine FSM is totally flat. I assume your machine is hierarchical, which makes certain transitions more complex and the associated code bigger. I also expect the code size to vary hugely with the agressiveness of the compiler at inlining and global optimizations. I hope I'll find the time to make some tests with switching these on and off.
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).
No worries, I don't think there will be much difference to the current version. Thanks for the tests, BTW. Best Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.