Re: [boost] [msm] Passing constructor arguments to submachine
Is it also possible to pass constructor arguments to submachines of a msm state machine?
Unfortunately, not yet. There was a proposal made during the review to allow states (including submachines) to be cloned from an existing one, but it is not implemented yet.
The Parameter library can sometimes be used to make this sort of thing work nicely. See Boost.Accumulators, for example.
I didn't think about Parameter and I like the idea (I also see somewhere else where it could be useful) but I : (a) don't have any parameter name to give to BOOST_PARAMETER_NAME (parameters being simply forwarded with BOOST_PP_ENUM_PARAMS) (b) don't know at preprocessor time in BOOST_PARAMETER_CONSTRUCTOR how many parameters the user will pass through the back-end to the front-end constructor or how many submachines/substates will be default-constructed by user's choice. Concretely, the user can now do something like: player p(/* for the front-end*/ 3, "a"); And adding states for copy-construction could look like: player p(/* for the front-end*/ 3, "a", /* some states copy-constructed*/ Paused("something") , Playing("more data") ); Of course I could provide some default names and create more constructor overloads with BOOST_PP_ENUM_PARAMS. I was actually thinking of using a proto expression like: player p( (/* data for front-end*/params_ << 3 << "a" ), (/* some states copy-constructed*/ states_ << Paused("something") << Playing("more data") )); But I admit having not spent enough thinking time yet so I will look into it again. Thanks for the idea, Dave. It will in any case be pretty cool to use Parameter to make back-end policies nicer. Christophe
At Wed, 2 Jun 2010 22:54:27 +0200, Christophe Henry wrote:
I didn't think about Parameter and I like the idea (I also see somewhere else where it could be useful) but I :
(a) don't have any parameter name to give to BOOST_PARAMETER_NAME (parameters being simply forwarded with BOOST_PP_ENUM_PARAMS) (b) don't know at preprocessor time in BOOST_PARAMETER_CONSTRUCTOR how many parameters the user will pass through the back-end to the front-end constructor or how many submachines/substates will be default-constructed by user's choice.
Concretely, the user can now do something like: player p(/* for the front-end*/ 3, "a");
And adding states for copy-construction could look like: player p(/* for the front-end*/ 3, "a", /* some states copy-constructed*/ Paused("something") , Playing("more data") );
Of course I could provide some default names and create more constructor overloads with BOOST_PP_ENUM_PARAMS.
I was actually thinking of using a proto expression like: player p( (/* data for front-end*/params_ << 3 << "a" ), (/* some states copy-constructed*/ states_ << Paused("something") << Playing("more data") ));
But I admit having not spent enough thinking time yet so I will look into it again.
Thanks for the idea, Dave. It will in any case be pretty cool to use Parameter to make back-end policies nicer.
Please take a close look at Boost.Accumulator; it has to solve essentially the same problem IIUC, and it does so quite nicely. You can't use the high-level macros like BOOST_PARAMETER_CONSTRUCTOR in the template that has to do the forwarding, though. I think it might even improve readability to do make your life easy and accept a single argument pack (backend_args in the example below) for forwarding to submachines player p(/* for the front-end*/ 3, "a", backend_args = ( init1=Paused("something"), init2=Playing("more data")) ); or something like that. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (2)
-
Christophe Henry -
David Abrahams