Re: [boost] boost [msm] deferring event by base type

Subject: Re: [boost] boost [msm] deferring event by base type
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2010-06-25 08:54:35

> I'm now using Row and Defer functor I have now an other problem whit the :
>
>      void defer_event(Event const&  e)
>      {
>          // to call this function, you need either a state with a
> deferred_events typedef
>          // or that the fsm provides the activate_deferred_events typedef
>          BOOST_MPL_ASSERT(( has_fsm_deferred_events<library_sm>  ));
>          execute_return (library_sm::*pf) (Event const&  evt)=
> &library_sm::process_event;
>          Event temp (e);
>          ::boost::function<execute_return ()>  f= ::boost::bind(pf, this,temp);
>          post_deferred_event(f);
>      }
>
> actually it tries to instantiate the base class ( Event temp (e); )
> but in my case the base class is an abstract class ->  compiler error;
> and after deferring I want to dispatch the original derived event not
> the copy constructed base class instance of the event.

What you get is a slicing. The Defer functor works like any action,
meaning that the type of the event is encoded in the transition.
If you consider a transition:

a_row < Stopped , play        , Playing , &p::start_playback
              >

and an action:

void start_playback(play const&)

The type of the event in the action is the one defined in the
transition. So what defer_event gets (from Defer) is the type defined
in the transition, in your case the base event. It's harder to spot
than a vector<base> but about the same.

A solution would be to have msm's process_event reinterpret_cast
action signature.
I will take it into my feature list but probably not at the top as I
consider the feature as only nice to have.

In the meantime, I, like Juraj, would also suggest you to pimpl your
data (with or without a shared_ptr) or define one entry inside
deferred_events for every derived event.

Regards,
Christophe