MSM: Separating templatized on_entry/on_exit into cpp/h
Hello, I'm trying to modify the Player example and to separate the on_exit/on_entry template function definition from declaration so I can hide the actual implementation details. "My.h" ... namespace myNamespace { ... // Concrete FSM implementation struct player_state_machine : public msm::front::state_machine_def { ... struct Playing : msm::front::state<> { template void on_entry(event const &, player_state_machine & ); // { "My Secret Code } } ...... } } "My.cpp" namespace myNamespace { ... template void myNamespace::player_state_machine::Playing::on_entry(Event const &, player_state_machine & ); { Here I want to put the actual implementation... } Is this feasible ? If not - what are the alternatives ? As I previously said - putting the implementation into the header is not an option. Any help will be appreciated. Evgeni -- View this message in context: http://boost.2283326.n4.nabble.com/MSM-Separating-templatized-on-entry-on-ex... Sent from the Boost - Users mailing list archive at Nabble.com.
Sorry for my late answer, I overlooked this message :(
Hello,
I'm trying to modify the Player example and to separate the on_exit/on_entry template function definition from declaration so I can hide the actual implementation details.
"My.h" ... namespace myNamespace { ... // Concrete FSM implementation struct player_state_machine : public msm::front::state_machine_def
{ ... struct Playing : msm::front::state<> { template void on_entry(event const &, player_state_machine & ); // { "My Secret Code } } ...... } } "My.cpp"
namespace myNamespace { ... template
void myNamespace::player_state_machine::Playing::on_entry(Event const &, player_state_machine & ); { Here I want to put the actual implementation... } Is this feasible ?
I'm afraid no.
If not - what are the alternatives ? As I previously said - putting the implementation into the header is not an option.
You could forward the on_entry call to a non-template method of Playing (or several overloaded non-template methods) which you only declare in your header and implement in a cpp. The state itself is usually not a template class.
Any help will be appreciated.
Evgeni
HTH, Christophe
Hi, thank you for the clarification. Unfortunately this type of limitations or design constrains really prevent Boost from being applied efficiently in production-grade code. 1. Exposing the "guts" is not applicable in wide range of applications, so using templates is this case actually makes this library less attractive. 2. In addition, the moment we put the business logic into the header files it's not a "class template" anymore, and therefore cannot be reused efficiently (not to mention the mess if header files includes). Thanks anyway, Evgeni -- View this message in context: http://boost.2283326.n4.nabble.com/MSM-Separating-templatized-on-entry-on-ex... Sent from the Boost - Users mailing list archive at Nabble.com.
Hi, thank you for the clarification.
Unfortunately this type of limitations or design constrains really prevent Boost from being applied efficiently in production-grade code.
I know of a lot of production-grade code using boost. Anyway I have no interest in starting such a discussion again.
1. Exposing the "guts" is not applicable in wide range of applications, so using templates is this case actually makes this library less attractive.
Well yes, this is not a java library. The template is made to avoid getting the event as IEvent then cast it to the one you hope to get. If your fsm becomes bigger and events start carrying data, you will get what I mean.
2. In addition, the moment we put the business logic into the header files it's not a "class template" anymore, and therefore cannot be reused efficiently (not to mention the mess if header files includes).
If what you want is hide your logic, you have other options, like for example: // PublicClass.hpp struct PublicClass { struct Fsm; boost::shared_ptr<Fsm> fsm_; // or boost::shared_ptr<void> fsm_; }; // PublicClass.cpp // provide definition of Fsm It's not that hard to hide your logic. Just add some interface methods in the public class, the OO way if you are allergic to templates and there you are. HTH, Christophe
participants (2)
-
Christophe Henry -
ev_mp