"Alexander Nasonov" <alnsn@yandex.ru> writes:
David Abrahams wrote:
What is "class state?" Can you describe its domain? What are the principle abstractions in that domain?
Ok, you catched me. In most cases, these members are shared across states. So, they have to be members of Fsm. Class states might hold a "baton" to pass on to a next state but I don't see any important use case.
Okay.
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.
The man who invented examples is the greatest inventor of all time! After looking at mpl example I understand what do you mean.
Good.
My code can be rewriten to support your style. You could typedef Running as state<0>, Stopped as state<1> and so on.
I'll ask again: what is the point of using types for states?
The framework could find out that all state<N> are stateless (what a mess! :) and left out storage generation for them. I wonder when and why you need these numbers?
You have to give the state some runtime-mutable representation, and numbers work very well as explained in the book.
Not for passing to switch statement, I hope?
It depends on the dispatching scheme you choose, but sure, why not a "switch statement?" The book's example generates the equivalent of a switch for each event type, using a cascade of inlined "if" statements. On on the CD there should be a version that does an O(1) lookup of a transition function in a linear table... oops, it didn't make it onto the CD. I've posted it here in the past, but it's attached again. I'm not convinced that it's faster to do it that way, though, for the typical state machine.
I suppose, you use them to check for a particular state of set of states like whether FSM is in final state(s) or not.
I'm sorry, "state of set of states?" I don't understand.
If you do so, I do so as well.
I don't know if I do so, yet ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com