On Sun, 2008-08-17 at 15:27 -0800, David Abrahams wrote:
on Sun Aug 17 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Sun Aug 17 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
State machines, as I see it, are meant to define an object behavior, IOW reduce the amount of undefined behavior. It is pointless to use them to implement undefined behavior.
So std::vector is pointless because it exhibits undefined behavior when misused?
No, vector is not pointless, because its purpose is to store elements, not to define behavior.
Sorry, but you're making no sense to me. The defined behaviors of vector are just as important as the defined behaviors of your FSM library.
Andrey appears to be saying that the whole concept of an FSM is built around defining the behaviour in reaction to events, while the concept of a vector is about storage and access to elements. His use of "behaviour" was a bit loose/context dependent/needed an FSM to interpret :-). Anyway, the OP (Phil) seems to believe that this particular issue arose out of a bad choice of example than being what he was trying to illustrate. That said, I'm still not clear on what exactly that was.
I will need vector to store elements even with undefined behavior on invalid pointers as its input. But why would I need FSM if it doesn't define my object's behavior?
Well, it would define useful behaviors for valid inputs.
Fair enough.
Or if I am adamant on what particular input will come from the environment (IOW, the behavior is already defined by the environment)?
The OP's assumption only works when you have sufficient control over the inputs.
Right. However, in this trivial FSM where much of the state is directly encoded in a couple of variables,there is no need to deal with invalid inputs and the FSM has no deeper behaviour/actions; *any* FSM library looks verbose. What we are comparing is DSELs, and, while you say that it would be good to be able to embed the diagram, the diagram in the USB example is an incredibly verbose representation (by count of nodes and edges) of what is described by Phils code. Obviously you don't infer from this that any attempt to embed state diagram (like) representations in code is pointless, but you do seem to find the proposed libraries representation less useful. Is it simply that the "states that handle events" model is intrinsically not as clear as a diagram or transition table, or is there some unnecessary verbosity or lack of clarity in way that model is expressed in the language implemented by the library?
Please, have a look at my reply to Phil. I've attached a code snippet with a transition map. Does that look more declarative?
Not really, to me. It's very difficult for me to see the transitions in that code. Compare that with either of my player examples.
Hmm... I don't see much difference, except for comments markup. Both code samples use transition maps, both use vectors... Is it because the transition map in your code is a member of the complete FSM?
There are 2 examples attached - the second with a transition map. I rather like the fact that the library allows transitons to be defined by a transition table as well as by defining event handlers/transitions within each state.
The STT in my code is clearly visible at http://svn.boost.org/trac/boost/browser/trunk/libs/mpl/example/fsm/player1.c...
Where's yours?
I've pasted it here: typedef mpl::vector< fsm::transition<Attached, fsm::event<PowerOn>, Powered>, SetAddressTrans<Default, std::not_equal_to, Address>, SetAddressTrans<Address, std::equal_to, Default>, SetConfigurationTrans<Address, std::not_equal_to, Configured>, SetConfigurationTrans<Configured, std::equal_to, Address>, fsm::transition<fsm::any_state, fsm::event<Reset>, Default>, fsm::transition<fsm::any_state, fsm::event<PowerOff>, Attached>
::type Transitions;
Regards Darryl