[msm] Injecting events to FSMs from different translation units
Hi, I am using boost msm to design state machines for a relatively large project. The documentation online is pretty good and I was able to figure out most features by looking at the sample code (thanks!). My particular application has multiple FSM instances active at any given time, and what I would like to do is to be able to generate events for a particular FSM instance from different translation units. But I'd like to keep the the compile time at a minimum. I found an answer from Christophe for a similar question sometime back here: http://stackoverflow.com/questions/10899641/boost-msm-class Since, I have multiple FSM instances it would not help to have a singleton class with the FSM shared_ptr. I am looking for ideas/suggestions/experiences for implementing this in an elegant OO ways. Thanks, Samriti
On 13.5.2013. 23:27, samriti katoch wrote:
Hi,
I am using boost msm to design state machines for a relatively large project.
The documentation online is pretty good and I was able to figure out most features by looking at the sample code (thanks!).
My particular application has multiple FSM instances active at any given time, and what I would like to do is to be able to generate events for a particular FSM instance from different translation units. But I'd like to keep the the compile time at a minimum.
I found an answer from Christophe for a similar question sometime back here: http://stackoverflow.com/questions/10899641/boost-msm-class
Since, I have multiple FSM instances it would not help to have a singleton class with the FSM shared_ptr.
There is no singleton in the proposed solution. The proposed solution merely hides MSM guts from public headers to reduce compile time (pimpl idiom). Nothing is stopping you from creating multiple instances of PublicClass. I think shared_ptr is causing the confusion - it is merely an implementation detail, data it points to is not intended to be shared between different PublicClass objects. You could also have use a plain pointer (but then you need to consider copy semantics), or scoped_ptr (which would make this class non-copyable).
There is no singleton in the proposed solution. The proposed solution merely hides MSM guts from public headers to reduce compile time (pimpl idiom). Nothing is stopping you from creating multiple instances of PublicClass.
Exact.
I think shared_ptr is causing the confusion - it is merely an implementation detail, data it points to is not intended to be shared between different PublicClass objects. You could also have use a plain pointer (but then you need to consider copy semantics), or scoped_ptr (which would make this class non-copyable).
It's just safer than a pointer, which I avoid giving as example ;-) and easier to use than a scoped_ptr. Juraj is right, all these ways are correct. Only plain values or references would not help you as they'd force all the template instantiations into every TU including your header. Furthermore, it's considered bad style to give access to the internals of your fsm, populate instead PublicClass with public members processing events in the .cpp file. Thanks, Christophe
participants (3)
-
Christophe Henry -
Juraj Ivančić -
samriti katoch