Hi Andreas,

:-) You won't get any flames from me. Yes, I don't agree with some of the points in MsmSession_Handout.pdf (e.g. 2.4, a user in his right mind would put Stopped, Open, Paused and Playing into an outer CDLoaded state and then only say if (state_downcast<const CDLoaded *> != 0)).

True, it is a possible solution. But 1) you don't always want to refactor your state machine and 2) sometimes you can't. For example, to take the example in the Statechart documentation(http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/tutorial.html#State...), if ( ( state_downcast< const NumLockOff * >() != 0 ) && ( state_downcast< const CapsLockOff * >() != 0 ) && ( state_downcast< const ScrollLockOff * >() != 0 ) ) could have been replaced by if(fsm.is_flag_active<IsOffState,Active::Flag_AND>()). And in this case I don't see a working refactoring solution. In my experience, the flag system has proven invaluable (to define, for example, several success states in a test case defined as a state machine).

However, although I haven't yet reviewed anything in-depth so far, I'm definitely impressed by the progress the library has made. I hope I'll find the time to contribute an in-depth review.

This would be great and your experience could prove invaluable. I'd be very thankful for it.

Out of curiosity, have you made any tests how many states compilers can manage without running out of memory? IIRC, a Boost.Statechart FSM with 128 states and several hundred transitions was the most I was able to fit into one TU.

Good point indeed. There are 2 limitations. First, Msm is based on boost::mpl::vector for the transition table and on boost::fusion::set to contain the states. Both have a default limit of 20, which can be extended to 50. This is the theoretical limit. Of course, you can add some vectorxxx.hpp headers (which I did). I tried up to 80 transitions and 80 states in one machine. The second limitation is the compiler. The test compiles on VC and g++, eventhough you might need lots of RAM (1.4GB with VC9, 400MB with g++) and 40-60s. The execution speed stays the same, thus proving the O(1) double-dispatch. I suppose that, while it must be possible to push this further, Boost.Statechart will likely break the compiler later than Msm. Regards, Christophe Henry