Hi Christophe
Bad news I have tried to add an internal event table to my state base class that it is forwards the event to the outer one if the state machine where the state is used is a sub state machine.
I have added a line something like this :
struct internal_transition_table : boost::mpl::vector< // Event Action Guard // +-----------+------------------+---------------+ bMsmFr::Internal < BaseEvent , IntFwdToOuterFct , bMsmFr::none > // +-----------+------------------+---------------+ > {};
IntFwdToOuterFct check when ever the event can be forwarded to an outer state machine ( is there an outer state machine ) and if there is one it calls the interface function to process it. if there is none that prints a warning that the event is not handled in this state.
Yes, should be correct.
before this change when I compiled the same state machine the compiler was using up 1.7 GB heap to compile this particular CPP file. Whit the change above I get a following error and a crash in a compiler when the heap usage reaches 4.2 GB
\boost/mpl/for_each.hpp(69) : fatal error C1060: compiler is out of heap space
I was using VC9 64bit version on win7 64bit with 12G memory ......
Usually, this doesn't help with VC9 :(
So by adding the internal transition table makes compiler heap usage to grow around by 300 %
So I can not compile such a code....
Cheers Richie
This is strange because it's not the kind of feature which typically hurts the compiler, so I suspect some of the regular VC9 "surprises". I tried with VC10 on some big state machine and the difference was almost none on heap and compile-time. If you could send me an example, I could play with it and see what can be done. In the meantime, we can try the following: - compile with VC10 to see if you see a difference in heap and compile-time with/without internal transitions. - if ok, we try the usual culprits: do you compile with /Gm- (minimal rebuild)? Don't. - is /Zm on? Usually we don't need it. You can also try with different values. Interestingly, usually, smaller values work better than large ones. Regards, Christophe