Boost logo

Boost :

From: Darryl Green (darryl.green_at_[hidden])
Date: 2008-08-18 23:46:12


On Mon, 2008-08-18 at 14:49 -0800, David Abrahams wrote:
> on Mon Aug 18 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
>
> > David Abrahams wrote:
> >> on Sun Aug 17 2008, Darryl Green <darryl.green-AT-aanet.com.au> wrote:
> >>
> >>> in this trivial FSM where much of the state is directly
> >>> encoded in a couple of variables,
> >>
> >> I don't know what the number of variables has to do with anything. For
> >> all practical purposes, unless you allow nested states or other esoteric
> >> extensions to the traditional CS meaning of FSM, 16 bits is more than
> >> enough to encode the state of arbitrarily complex state machines.
> >
> > I'm sorry, I don't follow you. The question was not about how to encode
> > the state but about whether FSM concept is needed here.
>
> I'm as baffled as you are about why Darryl brought up the number of
> variables required to encode the state. :-)
>

I assumed we all agreed that the number of variables required to encode
the state is 1, and that the number of bits required was/is utterly
irrelevant. My point is that the example is so trivial that it didn't
need an FSM. Andrey had said effectively the same thing but it
degenerated into a debate about input checking. I was trying to approach
it from a different angle to avoid that. Last try:

The following is not an FSM by any reasonable definition and implements
the same behaviour as Phils code. Is it now clear why I was saying that
the whole discussion surrounding this non-FSM is completely
non-productive in evaluating the utility of an FSM library?

struct usb_device
{
bool power;
int address;
int configuration;

void power_on() {
  power = true;
}

void power_off() {
  power = false;
  address = 0;
  configured = 0;
}

void reset() {
  power = true;
  address = 0;
  configured = 0;
}

void set_address(int addr) {
  address = addr;
}

void set_configuration(int cfg) {
  configuration = cfg;
}

};


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