Re: [Boost-users] Boost MSM: Can not get out of the submachine

Subject: Re: [Boost-users] Boost MSM: Can not get out of the submachine
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-06-06 14:10:15

>> I tried and it worked. I did:
>> - declare pseudo exit: struct payment_done: public 
>> exit_pseudo_state<none>
>> - change inside transition: Row < check_payment, none, payment_done, 
>> none,
>> is_paid>
>> - changed outside transition: Row < Payment::exit_pt<payment_done>, none,
>> waiting, dispense_item, none>
>>
>> And it compiles and does the work (from what I understood of your
>> program).
>> I tried with the newest version. If you still have a problem, it might be
>> an
>> old bug. What version are you using?
>>
>
> -->
> I got it working too. I was defining the payment_done state as struct
> payment_done: public exit_pseudo_state<>, instead of struct payment_done:
> public exit_pseudo_state<none>.
> I corrected it and now the code is compiling without error.

Ok, good.

>> An elegant way to do this is to add this info in the event. Like this you
>> can save it in Payment (you get the event in on_entry and the target 
>> state
>> is also passed to the transition).
>> I like to see this as the UML equivalent of a function call.
>>
>
> -->
> As per my understanding, it will be possible to convey the info through an
> event only if two states are "connected" by an event. But if one has to
> access info in one state from another state and if they are not connected 
> by
> an event as such, what will be the best way to do that? (In the vending
> machine example, the product gets selected in the "selection" state and 
> gets
> dispensed in the dispense_item action. These two are not directly 
> connected
> through an event.) I can think of one way (not sure if its the best way to
> do that though) where the state machine itself stores pointers to objects
> that represent states. (eg: state machine have a pointer struct selection
> *sel_ptr; The selection state on entry will then update this variable with
> "this" ptr. i.e the on_entry method of selection state will have a
> statement: sel_prt = this;).  This won't however work if a submachine has 
> to
> access info stored in the parent machine.
>
> Thanks!

In your case, I think it'd make sense to pass it in the event going from 
selection to Payment because the choice is the result of selection, right? 
Then Payment could store it (or a reference/pointer to it) in its on_entry.
A second possibility (but IMO less clean) solution would be to add an action 
in the transition selection - key_press - Payment. This action would set the 
info into the target state (Payment). Then your submachine works with 
correct data.
The third possibility (we're getting less and less clean here) is for 
on_entry of Payment to access the info from its parent state machine (the 
FSM parameter, as Payment is a substate of your vending_machine).
And finally, the method to use when nothing else works, get vending_machine 
or selection set the data directly inside Payment (using 
get_state<Payment&>) during the transition (as selection::on_exit or 
transition action method).
I don't think you'll be happy to have the submachine get info from its 
parent using a pointer trick. This sounds like circular reference to me and 
this usually finishes bad.

HTH,
Christophe