Scott Woods wrote: >> this is a product i used a few years ago. its a pretty complete >> "implementation" >> of SDL - you draw SDL, push a button and it generates the target >> system >> in C (that's what the brochures say ;-). it is very much targeted at >> large communities of FSMs. >> >> the sort of thing that i queried a while ago (and i think related to >> what chris was >> asking) was; "where is the [separate] definition of the protocols"? >> right or wrong >> i believe that FSMs interact through sending of signals >> (presentation of events?). >> this interaction is a protocol and a protocol has its own >> "existence" - it is not >> owned by the FSMs. neither UML or SDL highlights this. using SDL i >> was certainly able to implement protocols but it would have been a >> royal pain to uplift that "protocol" and reuse it in another project. > > Hmmmm. Apologies. Just had a read of some of the UML material and have > to take this back. My knowledge of UML needs updating. It looks like > OMG is competing with ITU pretty damn successfully these days. > > Putting that fight aside for a moment (UML vs SDL) the separation of > protocol from FSMs is maybe a concept of interest to you and your > library. But truly see this as just "future" stuff. Looking forward > to current functionality.
I don't know what part in the UML specs you're referring to (I don't really know UML apart from class diagrams and state charts). A quick search did not reveal much apart from protocol state machines which AFAICT don't have anything to do with FSM interaction. SDL defines channels, gates and connections which sort of define a protocol. To me, these primitives are only necessary to *document* which FSM is talking to which other FSM. There's little semantics behind them. Maybe I'm seeing this too easy but I think in C++ all you need for inter-FSM communication is: 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. Let's assume we already have a thread-enabled boost::fsm. We would then have something like concurrent_state_machine::queue_event( const intrusive_ptr< const event_base > & ) Now if FSM A wants to send a request to FSM B and make B send an event back as soon as the request is processed, we could write something like this *B.hpp*: struct Answer : fsm::event< Answer > { /* answer params */ }; struct Request : fsm::event< Request > { /* request parameters */ boost::function< void ( const intrusive_ptr< const Answer > & ) > callback; }; struct B : fsm::concurrent_state_machine< B, /* ... */ > { static B & instance(); }; *B.cpp*: // X is some state of B fsm::result X::react( const Request & req ) { // ... intrusive_ptr< const Answer > pAnswer( new Answer() ); req.callback( pAnswer ); } *A.cpp*: #include "B.hpp" // somewhere inside A's logic: 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. Regards, Andreas _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost