Re: [boost] [MSM] feature request stop(const event& event_)

Subject: Re: [boost] [MSM] feature request stop(const event& event_)
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-04-01 14:52:56

> Hi Christophe and all
>
> Now I have to put some effort to residing out code using MSM because
> one of our module where we use MSM has reached it's limits and we
> won't be able to compile it any more with VC9 32 bit compiler.
> In our implementation we have several sub state machines (around 20
> per main state machine instance at the moment) ( nested in 4 level
> deep) and over time as we extend the functionality we introduce new
> sub state machines which are covering new functionality ...
>
> We now can not add any more new sub state machines because we can not
> compile any more :(.

While big improvements were made, there will always be a limit,
especially with VC9. Did you try with VC10? It'd be interesting to
know.

> So I have decided to split the big state machines with a lot of subs
> state machines to stand alone small state machine instances and use
> our dispatching framework to dispatch events between them. This way I
> will get small compile units.

Sounds good.

> I'm managed to complete a job apart form one problem I have now.
> I'm not able to generally trigger the exit functions on the current
> active states of a state machine when it is finished it's execution
> like when a sub state machine exists to the outer state machine.

If you mean in the fsm destructor, it's true. I'd be surprised though
if on_exit was not called when leaving a submachine to its outer.

> Is it possible to implement something like stop method on the back end
> which would call exit on each region current state and than an exit of
> the state machine whit an event passed as an argument. ?
>
> this would help me a lot and it would be similar to the start.

Ah yes I remember thinking about it in the early phase of MSM.
Unfortunately I don't remember why it was not done, just that I had a
reason at that time.
Actually I think it'd be even better to automatically call on_exit in
the destructor. The start method is there only because you might not
want to start a state machine immediately upon creation, but I have
never had a very good feeling about it, so I'd prefer not repeating
this.
Is there a reason why you want a stop method or the calls of on_exit
inside the destructor would suffice (provided I don't hit again the
issue I mentioned above)?

> other minor thing is it possible to make public this version of start
> methode in the back_end ?
>
>    template <class Event>
>    void start(Event const& incomingEvent)

I'm not sure you'd be happy with this because on_entry is not called
in this version (it's meant to be called from the outer machine, which
itself calls on_entry), so you'd have to call it yourself.
What are you trying to achieve?

Regards,
Christophe

>
> Br.
> Richard