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