[Boost-users] [MSM] Solution for: fatal error C1202: recursive type or function dependency context too complex

Subject: [Boost-users] [MSM] Solution for: fatal error C1202: recursive type or function dependency context too complex
From: Mark Bartosik (mbartosik_at_[hidden])
Date: 2015-10-21 17:12:03

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