Re: [Boost-users] [MSM] how to use a compilation firewall around inner state machines

Subject: Re: [Boost-users] [MSM] how to use a compilation firewall around inner state machines
From: Mark.Bartosik_at_[hidden]
Date: 2014-07-30 14:21:45

Repost from different email client (prior ate linefeeds, sorry again).

I have a state machine implemented with MSM (eUML) that currently has 80 transitions, there are two inner state machines.

Compilation time is not great, but I have been dealing with it by BOOST_MSM_FAVOR_COMPILE_TIME and using parallel compilation where possible.

Slow compilation time is an irritation and productivity killer, but my larger worry is that eventually the compiler will run out of memory. Especially as I will likely have to add another inner state machine with about 40 more transitions.
Current we are using VS2008 but planning on moving everyone in the team to the VS2012 toolset but running under the VS2013 environment. I don't know if this will help, I doubt it. Currently compilation memory usage is up to 2.5GB per translation unit.

So I would like to use a compilation firewall around the inner state machines.
My plan is to implement concrete types for the  inner state machines, with a process_event function:

  boost::msm::back::HandledEnum process_event( const boost::any & event );

Then within this function test for each event type to be handled by the inner state machine, and forward to a regular MSM state machine contained within the inner concrete type. I am hoping that this, plus on_entry and on_exit functions is about all I need to do. I expect that I will be able to get this to work, although an example on how to put a concrete wrapper around an inner state machine would be great, and importantly a list of limitations and work arounds for this technique would be helpful.

My problem is that the outer state machine transition table has rows like this:

  exit_pt_( inner_state,  inner_state_some_pseudo_exit_state )  / do_some_stuff()  == outer_s2,

  exit_pt_( inner_state,  inner_state_other_pseudo_exit_state )  / do_other_stuff() == outer_s3,

If inner_state becomes a concrete type, then I don't know if this can be handled, and if so how?

My best idea so far is for the inner_state to call process_event on the outer state machine and rewrite the outer machine's state transition table thus:

  inner_state + some_synthetic_event  / do_some_stuff()  == outer_s2,

  inner_state + other_synthetic_event / do_other_stuff() == outer_s3

The xxxx_synthetic_event's would be generated from within the inner state machine when it reaches one of the pseudo exit states.

So in summary I would like to know:

1) Is there a documented example of putting a concrete wrapper around a inner state machine.

2) What is the list of limitations of doing this. e.g. exit_pt_ not working.

3) How should I deal with transitions in the outer state machine that were making use of exit_pt_ 

P.S. I've got to say that I think MSM is great!

thanks 

 - - Mark