Re: [boost] [msm] Boost MPL vector limit size exceeded

Subject: Re: [boost] [msm] Boost MPL vector limit size exceeded
From: Richard Szabo (sz.richard_at_[hidden])
Date: 2010-09-01 17:11:12

On 1 September 2010 22:34, Christophe Henry
<christophe.j.henry_at_[hidden]> wrote:
>>> I personally defined myself headers up to 100. It's pretty easy actually.
>> Can you provide us the files that we don't have to do it ? We did it for 60 now.
>
> Sure (provided this is not rejected). I tried with 1.42.
>
>> We have problems that the compiler runs out of heap if we include too
>> many transitions as well.
>
> Juraj told me not long ago (but too late to make it into the 1.44 doc)
> that specifying LESS heap for VC (I think it is the Zm option)
> actually works better than increasing it.
> You could try it and see if that helps.
>
>> But our state machines are complex in our interfaces we have over 100
>> different events.
>> We have several main state machines whit 3 level deep substate
>> machines and around 10 substate machines altogether at the moment,
>> but actually as our feature list is growing with the current design
>> we are planning to add more and more substate machines to the system.
>> So we run out of 50 transitions in the main state machine pretty fast.:(.
>>
>> If we would split the implementation to several main sate machines we
>> would loose the nice features we gain with hierarchical approach.
>>
>> Is it not possible to use favor_compile_time feature or something
>> similar as described in
>> http://www.boost.org/doc/libs/1_44_0/libs/msm/doc/HTML/ch03s05.html#d0e3642
>> to avoid using the performance improvement and have the substate
>> machines to dispatch all events again in them this would allow as to
>> continue with our implementation because none of our transaction table
>> contains more than 50 entries alone.
>
> Yes, it would work but I think I remember you mentioning boost::any
> not being an option. If boost::any and the performance loss are
> acceptable for you then it would probably help.

Yes I remember now, this was the problem with -no_rtti compiling with GCC.
This part of the code with these complex state machines are not that
performance hungry
I will try it with  favor_compile_time option tomorrow again but we
give a try already with no success
we were still running out of vector size but we might not setup
correctly the state machines and cpp files.
I will let you know tomorrow.

Thanks for the help and for the hope to avoid big changes in the our
implementation. :).

Br.
Richie

>
> Regards,
> Christophe
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>