Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-02-12 14:11:18


"Alexander Nasonov" <alnsn_at_[hidden]> writes:

> David Abrahams wrote:
>> "Alexander Nasonov" <alnsn_at_[hidden]> writes:
>> > struct Running { /* stateful */ };
>> > struct Stopped { /* stateful */ };
>
>> Even more confusing; now you need a dynamic allocation
>
> Why I need it?

I am assuming states come and go when the state of the machine
changes. I suppose you can just keep a separate object of each state
type alive continuously...

>> to represent and change the current state of the machine. I
>> suppose you could use variant,
>
> That's one possible representation

...in that case states _do_ come and go.

>> but I never understood why people want to put state _inside_ of
>> states -- it doesn't match up with the domain abstraction of state
>> machines. The state's identity should be enough.
>
> There are two kinds of state: state of machine and class state.
> They're from different domains.

What is "class state?" Can you describe its domain? What are the
principle abstractions in that domain?

> Suppose Running state has m_speed member. Is it worth adding this
> member to the state identity?

Here you're arguing from a position that assumes states should have
state, but that's the assumption I'm challenging.

If I try to map what you're describing onto the state machine designs
that we did for "C++ Template Metaprogramming" (and that I posted
here), I could achieve something similar by simply putting storage for
auxilliary data (like speed) in a data member of the derived FSM
class.

While I have to admit that your particular example seems to naturally
call for associating that auxilliary data directly with the state
class, that model doesn't generalize well AFAICT. There could be
auxilliary data that's needed -- persistently -- for more than one
state.

> PS: We are ahead of time, boost::fsm review is scheduled on Feb 21
> :)

:)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk