Hi Richard,

I have tried out the new feature of msm : using constructor arguments for substate/machines : namely :

player p( back::states_ << Playing(back::states_ << Song1(some_Song1_data)) , boost::ref(data),3);

see doc : http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s05.html#d0e2320

I have some problem with it :(.

this case state Playing and Song1 will be constructed first with default constructor in back end constructor than the internally constructed Playing and Song1 will be assigned to the newly construed Playing / Song1 copy which got copied by value.

Copied by reference actually (unless I have a bug) and then assigned.

The only reason to use this feature is to able to use reference members in the substates

Actually not, I must have explained incorrectly because I see it purely as syntactic sugar as a replacement for most uses of fsm.get_state<Song1&>() or worse fsm.get_state<Playing&>().get_state<Song1&>().

but for that reference members must be initialised in the member initialisation list of the constructor of the substates in order to provide the references constructor arguments must be used.

Ok you'll have to use pointers.

Since subsates must provide default constructors it is not possible to always initialise reference members from outside. Furthermore substate must be copyable and must implement assignment which brings more harm than good :(.

Is there a way to resolve these problems ?

This seems to me at least slightly exagerated. Assignable is a requirement for types inside a STL container and the STL clearly brings more good than harm ;-) Joking aside, there is no easy solution. To avoid assignment we will need move semantics. I'm waiting for Boost.Move to be officially part of boost to support this. OTOH the solution hardly qualifies as simplier than an assignment operator, only faster. For the default constructor, the situation is not better. I'm using a fusion::set to hold the states and the doc doesn't mention the possibility to copy-construct a set from a smaller one (in our case). I tried it and it doesn't work. So for the moment, it seems I'll have to live with the current solution (default-construct the set, then assign the provided states) and you might have to resort to pointers. In any case, a solution will at least include copy/move-construction. I actually think there might be a way to patch fusion to avoid default-construction, but I have little wish to try this at the moment. I have limited development time (my nights) and it seems to me like a poor usage of this limited resource seeing the amount of features I still want to add into MSM (there will be a whole pack for the 1.46 and I have more in my plan). However, I am working by iterating so I will probably come back to it at a later time.

PS: Looking to the test: http://svn.boost.org/svn/boost/trunk/libs/msm/test/Constructor.cpp

I think there is a bug : at with line : fsm.context_ = 20;

Probably. It should be fsm.context_.bla = 20; Thanks, Christophe