Hello, I'd like to define some events of my state machine as templates that would be instantiated just before posting to the state machine. However, it seems that there is no way to define reactions with unspecialized templates, so I have to specialize them at the stage of reaction definition. The way to do this I can think about is to parametrize the state machine itself. But this means parametrizing *all* the states: template<class MyType> class MyFSM : public sc::asynchronous_state_machine{public: typedef MyType Type; //....}; template<class MyType> struct MyState : sc::simple_state{ sc::transition; // or: sc::transition;}; Besides, all the state machine then should be defined in the header file.. Do I miss something? Is there some less weird way to do this? Thanks a lot, Igor'. _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx

Hi Andreas,> > Besides, all the state machine then should be defined in the header> > file..> > Do I miss something? Is there some less weird way to do this?> > I'm afraid, I don't see any good way how you could do this. May I ask why > you'd need to define a reaction for a templated event?> The application I'm working on is a client that communicates with some proprietry streaming server. The streams are very different in many aspects, so the class representing a stream is designed as a template parametrized by stream type. The above state machine is instantiated from within this parametrized stream class. Basically, the machine is responsible for managing stream states as a result of input events, and propagating "command" objects carried by some events. In general, such an event is defined as follows: template struct EvCommand : sc::event<MostDerived>{protected: boost::shared_ptr<Command> command_; EvCommand(const boost::shared_ptr<Command> &command) : command_(command) {}public: boost::shared_ptr<Command> getCommand() const { return command_; }};(intrusive_ptr should be used here, but this doensn't matter right now) Then, actual "command carriers" are defined this way: struct EvLogin : EvCommand { EvLogin(const boost::shared_ptrProtocolCommands::Login &command) : EvCommand(command) {}}; ...where ProtocolCommands::Login is actual command to be wrapped. Later, the stream object creates this event and queues it to the state machine scheduler. The transition action for such an event tipically looks like this: template<class Event> void SomeOuterState::dispatchCommand(const Event &ev){ getCommandDispatcher()->send(ev.getCommand());} The problem is that sometimes specific command type depends on the stream type and must be "deduced" as a part of stream template instantiation, so it's defined like this: template<class StreamType> struct EvStart : EvCommand{ EvStart(const boost::shared_ptr<typename StreamType::StartingCommand> &command) : EvCommand(command) {}}; While from the state-chart point of view, the EvStart is always the same, despite the actual command type it carries. Of course, the events could "wrap" just some common interface of the commands, but for some reasons I'd like to preserve the actual type of the command at this stage... So I parametrised all the states, moved the implementation to the header file, and... it ceased to compile! Now it says: "1>d:\dev\servision\projects\windows\thirdparty\boost\boost\statechart\simple_state.hpp(188) : error C2039: 'inner_context_type' : is not a member of 'StreamSession::Active<StreamType>'" Where StreamSession is my asynchronous_state_machine, and the Active is the outermost state. The error occures when trying to instantiate the initial inner state of Active. So I'll appreciate any idea about the cause of the above error, as well as about the approach in general - is it ok or I missuse the framework. Thank you a lot, Igor'. _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE

...

So I'll appreciate any idea about the cause of the above error,> > Have you read > http://www.boost.org/doc/libs/1_35_0/libs/statechart/doc/faq.html#TemplatedS...

Oh, yes... thank you :) Actually, I've read all the tutorial and FAQ, but, as always, the useful things were written to some bad sectors of the brain... _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

Rene Rivera wrote:

Anthony Williams wrote:

...

Markus Werle writes:

...

Anthony Williams writes:

...

...

I would be grateful if you could provide patches for the 1.34.1 branch and the 1.35.0 branch as http downloads. No access via svn via the firewall over here ... I've attached a patch for boost/thread/win32/condition_variable.hpp vs the 1.35.0 release to this email.

NOTE: For future reference, you can access all the SVN files through http directly. For example the above is available here http://svn.boost.org/svn/boost/trunk/boost/thread/condition_variable.hpp.

D'oh, wrong link. This one should be better http://svn.boost.org/svn/boost/trunk/boost/thread/win32/condition_variable.h.... -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail