Re: [boost] [MSM] constructor arguments for sub state/machines

Subject: Re: [boost] [MSM] constructor arguments for sub state/machines
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-01-02 16:58:05

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