Closed sstiller closed 5 years ago
That is a great extension and gives more flexibility, where performance is not critical. I have thought about this also. Thanks :-)
Could you add a command line option which enables this? I like the generated state machines to be as simple as possible at not bloated with unused (depending on the use case) functionality as this and other future ideas are added.
Also, a few unit tests would be very nice to ensure the functionality won't be broken as the code changes.
is it ready to be merged in?
There are three things to do before merging:
Regarding eventless transitions. You mean this issue? https://github.com/jp-embedded/scxmlcc/issues/40#issuecomment-427275167
I will try to prioritize this as soon as I have time for it.
Regarding eventless transitions. You mean this issue? #40 (comment)
No, it's an other problem. I will create a new issue and / or PR for it as soon as I have time for it.
okay :-)
I did some performance tests for 8edcbed, the caching really helps a lot.
The tests work now, if the makefiles are used. msvs and cmake need fixing by someone who knows how to do it.
Currently only existing events can be triggered in the SM. Unknown events lead to compile errors (if the SM is changed, events can be removed from the implementation).
In my real world example I have a machine which does not know anything about the integrated state machine. It even does not know, which signals are possible, if event sources are added during runtime by a plugin.
Another problem: I want to be able to exchange the state machine implementation depending on the use case (the SM can also be loaded as a plugin). That means, I don't know, which events are implemented in the current SM.
There are more cases where I need much more flexibility.
For this reason I added a function to trigger an event with its name by overloading
dispatch()
. The most interesting commit is this one: https://github.com/sstiller/scxmlcc/commit/5c8a108bb3604cfa57ac64afbf56ba89154f0ff6I know, the performance is worse than the current solution, but it provides many possibilities like nice timer interfaces.
Before merging:
Maybe later:
ev1
, butdispatch()
is called with"ev1.foo.bar.something"
. Other example:dispatch()
is called with"ev2.foo.bar.something"
, butev2*
is not implementedWhat do you think about adding this code?