Re: [boost] [msm] Boost MPL vector limit size exceeded
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. Regards, Christophe
On 1 September 2010 22:34, Christophe Henry <christophe.j.henry@googlemail.com> 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
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@googlemail.com> wrote:
On 1 September 2010 22:34, Christophe Henry <christophe.j.henry@googlemail.com> 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
Now with reduced compiler error output. Br. Richie On 7 September 2010 12:22, Richard Szabo <sz.richard@googlemail.com> 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@googlemail.com> wrote:
On 1 September 2010 22:34, Christophe Henry <christophe.j.henry@googlemail.com> 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
participants (2)
-
Christophe Henry -
Richard Szabo