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 16:08:57

On 1 September 2010 19:12, Christophe Henry
<christophe.j.henry_at_[hidden]> wrote:
> Hi,
>
> Sorry for my late answer.
>
>> while building a state machine that also includes submachines, we exceeded
>> the possible max number of MPL vector entries (which is to 50 to my
>> knowledge) for transition tables.
>> Is there an easy way to solve that?
>> How to increase the max possible number of MPL vector entries?
>>
>> Do I have to manually create vector60.hpp and vector60_c.hpp? Or is there
>> something that generates all those files (also for larger vectors)?
>>
>> I also tried the define "BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS" with and
>> without specifing the define "FUSION_MAX_VECTOR_SIZE".
>> I tried the "favor_compile_time" vs "favor_runtime_speed" as well.
>> In both cases the MPL vector size was to small.
>
> 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.

> I didn't try the scripts.
>
> Erik Nelson wrote:
>>I used the #defines
>>
>>BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
>>BOOST_MPL_LIMIT_VECTOR_SIZE=60
>>
>>For my whole project and it worked for me. Â I wasn't using MSM, though
>
> I just tried it and it seems to work. Thanks Erik :)
>
> BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS will only help you up to 50.
> FUSION_MAX_VECTOR_SIZE is only to increase the number of states
> defined in a state machine (under the hood, a fusion::set is used to
> contain all the states).
>
>
>> Does it actually mean, in case we use submachines, that MSM generates a
>> flat transition table including everything in one MPL vector?
>> Example:
>> Main state machine consiting of 10 transitions + 1 submachine consiting of
>> 5 transitions.
>> Do we than have a transition table with around 15 entries that are stored
>> somehow in an MPL vector of size 15?
>
> You should get a look at
> http://www.boost.org/doc/libs/1_44_0/libs/msm/doc/HTML/ch05.html
> MSM generates an entry inside the main table for every event found in
> the submachines. This avoids forwarding events which a submachine will
> never be able to process (performance improvement).
>
> Juraj Ivančić wrote:
>>Finally I gave up and used the kludge described in the post referenced
>>above. Meanwhile I managed to trim down the number of transitions in my
>>state machine and got back into vector50 bounds.
>
> I also think that you might want to see if you can reduce the number
> of transitions if you can, because soon the compile-time will start
> hurting.

We have problems that the compiler runs out of heap if we include too
many transitions as well.
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.

but if it is not possible we have to know it ASAP because it has a big
impact in our design/ implementation which we need to do than
immediately.

Thanks in advance.

Br.
Richie

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