Re: [boost] [msm] guard behavior if guard guards the transition MSM threats event as handled is that correct ?

Subject: Re: [boost] [msm] guard behavior if guard guards the transition MSM threats event as handled is that correct ?
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-11-28 16:19:52

>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