Boost logo

Boost :

Subject: Re: [boost] [msm] Passing constructor arguments to submachine
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2010-06-02 16:54:27


>> > 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk