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

Subject: Re: [boost] [msm] Boost MPL vector limit size exceeded
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2010-09-01 13:12:22

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

Regards,
Christophe