Chris Knight wrote:
On Wednesday 06 August 2008 1:18:33 pm Andrey Semashev wrote:
Sorry, I still don't get it. You already can pass events with virtual functions and process them through base classes. The main problem with deferred events is that there's nobody to call process(deferred_event) of the FSM. Another problem is that you generally don't know the complete FSM type in states or transitions, but this issue is solvable with a change in the state and transition base classes.
Could you elaborate your point, please?
I think you basically have it. I agree that the deferred event processing while (events_to_process) { fsm.process_dynamic(event); } shouldn't be included in boost.FSM, the process_dynamic(event_c& const) function should be.
Using the TagV in the event_c class, it should be possible to provide a member function in state_machine to process events given only a reference to the event_c base class and that calls the appropriate process(event& const) via dispatching on the integer TagV.
I see. However, tags are not a good candidate to dispatch events on since different events can have same tags. I think, the event itself should contain enough information to be dispatched after being postponed. BTW, you can achieve the same functionality right now if you bind the event to the process function of the FSM and save the call into boost::function.
I'm trying to figure out whether this would be a simple feature addition or there is some critical piece I am missing.
I think, this would be an interesting feature to add in future releases. I won't be able to implement it before the review. State and transition base classes will have to be extended, in order to allow to postpone events. State machine and event classes will have to be modified too.