Boost Users :
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
>> - change inside transition: Row < check_payment, none, payment_done,
>> - 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
>> I tried with the newest version. If you still have a problem, it might be
>> 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.
>> 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
>> 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
> 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
> dispensed in the dispense_item action. These two are not directly
> 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
> access info stored in the parent machine.
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
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.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net