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-07 06:35:16

Now with reduced compiler error output.

Br.
Richie

On 7 September 2010 12:22, Richard Szabo <sz.richard_at_[hidden]> wrote:
> Hi Christophe
>
> Here is a little example I use favor_compile_time, (see attachment)
>
> But msm still tries to fold recursively all sub state machines states
> in to 1 big mpl vector.
>
> As you said in your last mail :
>
>>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.
>
> It would be possible to overcome this problem by using
> favor_compile_time but it seems apparently not :(.
>
> see error output in attachment as well.
>
> Thanks in  advance.
> Br.
> Richie
>
> On 1 September 2010 23:11, Richard Szabo <sz.richard_at_[hidden]> wrote:
>> 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
>>>
>>
>