Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-19 20:43:24

on Mon Aug 18 2008, Darryl Green <> wrote:

> On Sun, 2008-08-17 at 22:12 -0800, David Abrahams wrote:
>> on Sun Aug 17 2008, Darryl Green <> wrote:
>> > the diagram in the USB example is an
>> > incredibly verbose representation (by count of nodes and edges) of
>> > what is described by Phils code.
>> But Phil didn't encode the whole machine represented in the diagram.
> No - but most of what he left out was checking for invalid inputs that
> you have been claiming is not necessarily required. Adding in the
> suspended state tracking in an ad-hoc way would only need:
> bool suspended;
> void bus_inactive() { suspended = true; }
> void bus_activity() { suspended = false; }

yes, well I wasn't expecting such an ad-hoc approach; it's not a very
direct translation from the diagram.

>> > Obviously you don't infer from this that any attempt to embed state
>> > diagram (like) representations in code is pointless,
>> I do think it's pointless in C++, although I don't do it by inference
>> from anything you're mentioning.
> Wow! Does that mean you are against any FSM library or only one that
> tries to represent a diagram by some method other than an attributed
> edge list (state trainstion table)?

Umm, no, I just think there's no reasonable way to draw state diagrams
in C++ syntax (outside of comments).

>> > 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;
>> The bits enclosed by fsm::transition look like they might be rows in an
>> STT, although they're awfully verbose, with a great deal of surrounding
>> syntactic noise that distracts from being able to read the actual
>> semantics. AFAICT, the other parts do not bear any obvious resemblance
>> to rows in an STT.
> I agree that the convenience classes that Andrey put together to
> encapsulate the data dependend (gated) transitions are irregular. Can
> you suggest a better approach to deal with them?

not yet, I guess. I don't understand what they do.

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at