Re: [Boost-users] [statechart] Non-Const Machine Pass-throughs and state_cast

10 Aug 2009

      On 8/10/09 12:48 AM, Andreas Huber wrote:
...
...
The machine is effectively a timer and wraps another internal timer class
that can be stopped/started and suspended/resumed. This is all the machine
does. The internal timer class can get/set its interval and can also
get/set
a delegate, that is called (if set) when the timer fires. These internal
timer management interfaces are "passed through" to the state machine
interface, such that application/test code is as follows:
[snip code]
...
Where I have run into a problem is that my machine "pass through" setter
methods allowing the delegate to be set or the timer interval to be
changed
(neither of which materially alter the state of the machine) cannot be
called as they are non-const qualified whereas their corresponding getters
work fine since they are const qualified.
So both the values of the delegate and the interval are orthogonal to the
state the machine has? If so, I'm wondering why they're not members of
struct Timer? This would make ITimerManagement unnecessary and also save
quite a bit of code?
Andreas:

Making the internal timer a member of the state_machine was precisely my
initial implementation; however, initially, I'd found a destruction ordering
problem with that approach. Basically, on destruction of the running state,
I ensure the timer is stopped:

    struct Running :
        Interfaces::IRunning,
        Interfaces::ISuspended,
        state
    {
    public:
        typedef mpl::list<
            transition,
            transition > reactions;

        Running(my_context inContext) :
            Interfaces::IRunning(true),
            Interfaces::ISuspended(false),
            my_base(inContext)
        {
            contextMachine::Timer().Start();
        }

        ~Running(void)
        {
            contextMachine::Timer().Stop();
        }
    };

Initially, the machine and, in turn, the internal timer object appeared to
be destructed before the state, causing an assertion when I tried to stop
the destructed object.

There was also an assertion I had hit on construction of the running state:

    --> Implementation::States::Running::Running()
    Assertion failed: (get_pointer( stt.pContext_ ) != 0), function
context_impl, file boost/statechart/simple_state.hpp,    line 683.
   Abort

On revisiting my current implementation, neither of these no longer appear
to be the case. I now wrap the machine in another object and call
.initiate/.terminate:

    SuspendableTimer(void)
    {
        mMachine.initiate();
    }

    ~SuspendableTimer(void)
    {
        mMachine.terminate();
    }

This handles the destruction ordering correctly.

Through iterating on the const state_cast issue, I had also revised the base
of the Running state to 'state' rather than 'simple_state' which eliminated
the construction assertion for that state.

Thanks for the suggestion to revisit that implementation. The conditions had
changed but I hadn't reinvestigated once the conditions changed.
...
What is the purpose of the IRunning & ISuspended structs?
They are application-level pseudo-state queries.

Thanks for the tips!

Regards,

Grant

Re: [Boost-users] [statechart] Non-Const Machine Pass-throughs and state_cast

Grant Erickson