"Alexander Nasonov" <alnsn@yandex.ru> writes:
David Abrahams wrote:
"Alexander Nasonov" <alnsn@yandex.ru> 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