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:22:10

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
>>
>