...

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.

I like this syntax too. Ok then I will give it a try and have a closer look at Accumulator. Thanks!