Sorry this is a re-post because my email client had formatting enabled. I have had a major headache while using MSM eUML state transition tables, thankfully I've found a simple solution. First MSM and especially eUML are great, and that's why I persevered to find a solution. Here's the problem: Declaring a complex eUML state transition table may result in the compiler generating an error. BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE(( // row_1, // row_2, // ... // row_a, // row_b, // row_c, // // Eventually the Microsoft compiler VS2008,2010,2012,2015 will all explode with fatal C1202: recursive type or function dependency context too complex ), transition_table ); I haven't tried with gcc. The solution is to break the state table in two smaller parts rather than one big table: BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE(( // row_1, // row_2, // ... ), transition_table_part_1 ); BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE(( // row_a, // row_b, // row_c ), transition_table_part_2 ); typedef boost::mpl::joint_view< transition_table_part_1, transition_table_part_2 > transition_table; // No error, even though it contains just as many rows [Waffle warning] I think that what's happening is that once the compiler has fully described the transition_table_part1 it unwinds what it is doing, it is able to unwind and 'bank' transition_table_part1 as just being a type in it's memory, and when it comes to generate transition_table via boost::mpl::join_view it just constructing the resulting type list from two sets of previously 'banked' types. This is I think why I can still nest a sub-state machine which is on the limit of the complexity of state transition table it can contain; even though nesting state machines recursively references state transition tables. Things that did not work: [ more waffle ] There are some other solutions that I tried before I had the Eureka moment. One was to try to hide a sub-state machine within a concrete class but that didn't work because the outer fsm needs to see the inner stt. Another way was to implement a sub-state machine as a concrete state (not fsm), and then add a process_event method on the class which delegated to a member fsm which was hidden from the outer fsm, I got this to work, but it did not solve the problem, and I had to abandon use of exit_pt_, although it may have brought down compile times. Another helpful advantage of this solution is that the memory required by the compiler is significantly reduced. Christophe: Would you consider adding the example above to the MSM documentation, I would suggest under: Chapter 4, Compilers / Performance, Compilers Corner Also under: Chapter 5, Questions Answers and Tips: Question: Why do I get "fatal C1202: recursive type or function dependency context too complex" Answer: Likely because a state transition table has become two complex. Split the state transition table into two parts, and then use typedef mpl::joint_view< transition_table_part_1, transition_table_part_2 > transition_table to join the two parts. Question: Why does my compiler generate a fatal out of memory fatal error. Answer: Likely because a state transition table has become two complex. Try and split the most complex state transition table into two parts, and then use typedef mpl::joint_view< transition_table_part_1, transition_table_part_2 > transition_table to join the two parts. - Mark Bartosik