I think a comparison table between HFSM2 and FFSM2 would be interesting. Or, at least, a description of when it is more suitable to use one or another solution (strengths and weaknesses of each).
The main difference is that HFSM2 is hierarchical, and FFSM2 is "flat", which is to say it doesn't have regions, only root and it's immediate sub-states
Hierarchy brings a lot of complexity, so not having to support it also reduces compile times and memory footprint, improves perf.
Hierarchy brings a lot of complexity, so not having to support it also reduces compile times and memory footprint, improves perf.
So long as your FSM doesn't need hierarchy - FFSM2 is the way to go.
If it does - HFSM2 still has your back!
If it does - HFSM2 still has your back!
Great job!
Hey @AlexisTM
Yeah what you said made a lot of sense
Over time HFSM2 grew into a very powerful but also a bit heavy library
I addressed that in part with https://doc.hfsm.dev/user-guide/configuration/feature-macros
Trimming it down into a 'flat' FSM library was an obvious choice that would provide a lightweight FSM for simple uses, when HFSM2 can be an overkill
Yeah what you said made a lot of sense
Over time HFSM2 grew into a very powerful but also a bit heavy library
I addressed that in part with https://doc.hfsm.dev/user-guide/configuration/feature-macros
Trimming it down into a 'flat' FSM library was an obvious choice that would provide a lightweight FSM for simple uses, when HFSM2 can be an overkill
One design goal for FFSM2 was to make it easy to switch from HFSM2 to it, by changing
So far as the FSM itself is 'flat', in most cases it's possible to do just that, change the
hfsm2:: into ffsm2:: in the declarationsSo far as the FSM itself is 'flat', in most cases it's possible to do just that, change the
#include and the namespace and it should work, be a bit faster to compile, and have a slightly less of a memory footprint
Lastly, of course I listen to what my users say, why else would I ask them questions? :D