|
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