Hi Christophe,

I will check the thing with the cstor.

FYI: my library that uses the boost.msm-based state machine mechanism shall be released as shared library. It is used to realize Remote Procedure Calls. So my library consists of one Master state machine (which consists of 5 submachines and together 21 states) and one Slave state machine (which consists of 4 submachines and 19 states). The user application linking against my library has the possibility to choose if the slave state machine or the master state machine part shall be used. Now the problem could be, that I use a boost::variant type to store the 44 different application event types. This variant type I pass to the process_event method of each state machine (master and slave) although the slave state machine doesn't support the same event types like the master and vice-versa. This produces unnecessary template invocations and memory allocation. So the solution could be, to split my single shared library into two shared libraries: one for the master and one for the slave logic and each of it has a reduced boost::variant type( just with the event types of the concrete state machine). Or I keep the solution with the single shared library and I split the single boost::variant type into two different ones: one for the master and one for the slave state machine. And each boost::variant type will just be forwarded to the appropriate process_event method of the corresponding state machine. Doing so, will also prevent unnecessary template invocations for each event type on the corresponding state machine. Maybe this will also reduce the memory consumption...

What is your opinion about this two putative solutions?

Best regards (viele grüsse),

Rafael




Christophe Henry <christophe.j.henry@googlemail.com> schrieb:
----- Original Message ----- 
From: "RaRi" <degoah@gmx.de>
Newsgroups: gmane.comp.lib.boost.user
To: <boost-users@lists.boost.org>
Sent: Wednesday, February 27, 2013 6:44 PM
Subject: Re: Boost.MSM cc1plus.exe:: error: out of memoryallocating 65532


> Thank you all so far,
>
> I will investigate, how I can simplify my state machine and reduce the
> number of events.
>
> Damn, I spent 1 month on that machine and now I have to change it...
>
> On linux there is no problem with that. Okay, the memory exceeds 1 GB 
> while
> compiling my boost.msm based library. But it works fine!
>
> The problem what remains is to compile the stuff for windows.
>
> I have already just test one thing: Cross-compilation of my boost.Msm 
> state
>
machine on linux for windows with mingw32msvc-g++. But already doing this
> produced some errors:
>
> *../src/TransportLayer/Statemachine/Master/CStateMasterHandshaking.hpp:33:
> error: class ‘CStateMasterHandshaking_’ does not have any field named
> ‘BaseStateMachineFrontEnd’
> ../src/TransportLayer/Statemachine/Master/CStateMasterHandshaking.hpp:33:
> error: no matching function for call to
> ‘BaseStateMachineFrontEnd<CStateMasterHandshaking_>::BaseStateMachineFrontEnd()’
> ../src/TransportLayer/Statemachine/Master/../Common/BaseStateMachineFrontEnd.hpp:48:
> note: candidates are:
> BaseStateMachineFrontEnd<TYPE>::BaseStateMachineFrontEnd(EventQueue&) 
> [with
> TYPE = CStateMasterHandshaking_]
> ../src/TransportLayer/Statemachine/Master/../Common/BaseStateMachineFrontEnd.hpp:26:
> note:
>
BaseStateMachineFrontEnd<CStateMasterHandshaking_>::BaseStateMachineFrontEnd(const
> BaseStateMachineFrontEnd<CStateMasterHandshaking_>&)*
>
> I think, the MSVC-specific cross compiler is responsible for this error.
>
> I don't now, how to continue with this problem. At the worst I have to
> change the state machine completely.....
>
> Thanks so far,
>
> Rafael

Hi,

not sure how to help you there without code, but from what I see, I'd say 
that BaseStateMachineFrontEnd has a ctor which hides the default-ctor. Try 
to provide one and see if that helps.

I don't think you have to change it completely. Probably replacing a bunch 
of events by a single one containing an id as attribute, then checking it in 
a guard to see what event you really posted would probably be enough.

Cheers,
Christophe


Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users