[msm] guard behavior if guard guards the transition MSM threats event as handled is that correct?

Hi Christophe, Regarding our compile-time problem in the past and therefore, the changes Richard made: Would it be also feasible to develop an additional backend that is derived from the MSM one, but only implements the process_event() method for each event and not in a generic template-based way? With this approach we could still use MSM out-of-box and not having the need for internal transition tables or having references from inner to outer state machines etc but still gain small compiler units. I understand that we will loose flexibility and creating new state machines becomes more work, but I think we could live with that. What is your opinion? Am I thinking too short? Thanks, Michael

Hi Christophe,
Regarding our compile-time problem in the past and therefore, the changes Richard made: Would it be also feasible to develop an additional backend that is derived from the MSM one, but only implements the process_event() method for each event and not in a generic template-based way? With this approach we could still use MSM out-of-box and not having the need for internal transition tables or having references from inner to outer state machines etc but still gain small compiler units.
I understand that we will loose flexibility and creating new state machines becomes more work, but I think we could live with that.
What is your opinion? Am I thinking too short?
Thanks, Michael
Hi Michael, I'm not sure I understand your request completely. It's feasible to write a new backend (though it's a huge task because this is the whole engine of the library) but IIUC, your solution is exactly what MSM is doing now. You get a process_event for each event because the function is templated on the event type and generates different code. These process_event functions actually are what makes most of your compile-time. The task is probably much bigger because what you ask for is probably a completely new back-end. Regards, Christophe
participants (2)
-
Christophe Henry
-
Michael.Herchel@rohde-schwarz.com