Re: [boost] [fsm review] Comparison with ad-hoc FSM coding

16 Aug 2008

      Phil Endecott wrote:
...
Here is my ad-hoc implementation (note that I haven't tried to even 
compile any of this code):
struct usb_device {
enum state_t { Attached, Powered, Default, Address, Configured };
  state_t state;
int addr;
  int configuration;
usb_device(): state(Attached), addr(0), configuration(0) {}
void power_on() {
    state = Powered;
  }
void power_off() {
    state = Attached;
  }
void reset() {
    state = Default;
    addr = 0;
    configuration = 0;
  }
void set_address(int addr_) {
    addr = addr_;
    state = (addr==0) ? Default : Configured;
  }
void set_configuration(int configuration_) {
    configuration = configuration_;
    state = (configuration==0) ? Address : Configured;
  }
};
Phil -

While the term state machine can mean a lot of things, I'm not sure that
the ad-hoc implementation would represent what we all have in mind. For
example, according to your fsm.png diagram the only valid transition from
the Attached state is to Powered. However, nothing stops me from simply
calling the set_address method which will result in either a Default or
Configured state.

Even an ad-hoc state machine implementation should have some type of "tick"
or "clock" type method that takes a token or message (with or without 
payload).

So, while your ad-hoc machine will track a state if the methods are called
in a valid order, I'm not sure I would refer to it as a state machine.

Best Regards -
Michael

-- 

----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com