Boost logo

Boost :

From: Andreas Huber (ah2003_at_[hidden])
Date: 2003-06-15 15:49:37


Hi Scott,

[snip]
> But it seemed to
> be a successful modeling and I had to concede; why should a "niche"
> concept such as "protocols" foul the "global namespace" of a generic
> modeling language?

I see...

[snip]
>> 1. Events that can carry parameters
>> 2. A call-back mechanism a la boost::function, so that an FSM that is
>> answering a request does not have to know who it is answering to.
>>
> [snip]
>>
>> boost::intrusive_ptr< Request > pRequest = new Request();
>> // set params
>> A & machine = context< A >();
>> pRequest->callback = boost::bind( &A::queue_event, machine, _1 );
>>
>> B::instance().queue_event( pRequest );
>>
>>
>> So, IMO there's no need for boost::fsm to provide communication
>> protocol primitives, because their functionality is pretty
>> orthogonal to what my library does. Users would want to use what
>> they're accustomed to. Most would presumably use boost::function.
>>
>
> Yes. Think with 1, 2 and putting distance between boost::fsm and comms
> you have nailed something for me. Maybe there will eventually be a
> boost::signaling (damn
> thats somewhat overused) or boost::eventing (sounds like a horse
> race) that will
> complement your current targets?

I'm not sure I understand what such a library would do (there's already
boost::signals which covers publish-subscribe pattern, which BTW could be
interesting for certain types of inter-FSM communication too). Can you
elaborate?

[snip]
> I feel responsible for something of a detour into the subject of SDL
> and the comparison of UML with SDL.

I don't see it as a detour. It was valuable to see SDL's approach to FSMs.
It is even more valuable to see what questions might arise when people not
familiar with UML consider using boost::fsm.

> I hope that this detour has
> uncovered something of
> use for you (certainly has for me)

It definitely has. All that remains is that tiny last question ;-) above.

Thanks & Regards,

Andreas


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