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 -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-MSM-cc1plus-exe-error-out-of-memory... Sent from the Boost - Users mailing list archive at Nabble.com.