Usage for Debugging and Compiler warnings.

[phelter]

A few further suggestions - don't know if you'd prefer these as separate Issues.

• Separate out the static test suite into another header file. It's hard to read and identify the code that is supposed to be part of the implementation and what is part of the test. Can use:

#if not defined(NTEST)
#include <sml2test>
#endif 

This just makes it easier as a developer consuming the API to be able to search for the relevant information inside the #include <sml2> file.

• You have a requirement check - SFINAE for the sm.is(state<State>) - but for the developer if the state machine uses a state say "Idle"_s and you accidentally spell it "idle"_s instead of what is defined in the state machine, then the level of errors is quite cumbersome to use and is a deterrent for the design phase. If you could add some checks (I believe some sort of Concept requirement on the sm class execution of some functions for confirming that there is at least one state defined that is what you enter into sm.is("idle"_s). Suggest having the following concepts:
  • IsStateIn<sm.states, State> - used in sm::set_state(), sm::is(state)
  • IsStateNameSimilar<sm.states, State> - used in above checks as well - where it is not in state list but the to_lowercase of the string is equivalent - then provide the best suggestion of what to change the value to.
  • IsEventIn<sm.transition_table_, Event> - used in sm::process_event

This would at the very least identify errors at the development stage. Could possibly optionally enable those checks or provide an alternative function - eg sm::check_is(state) - or check_set_state(state) or check_process_event - that supports both.

This is by no means a critique on this code -but a critique more on the pain of errors printed out when using meta-programming.

• One key element that is missing is logging of state transitions - I believe instead of supporting in the base class of the sm with an injected logging facility like you have in the original sml. This would be really appreciated.

• PlantUML - conversion - I like the idea of auto-generating the documentation from the code rather than the other way around - would suggest having boost-ext/sml/.../plant_uml.cpp support for the sml2 as well - but as a stand-alone header that you can apply to any state machine. I'd use that in a heartbeat for every UnitTestSuite that included an sml2 state machine - spit out the state machine documentation as part of the Unit test suites....
  Question: - Does this work today with sml2 ?

[phelter]

Sorry for the wish list like this, but I thought I'd just give you an idea of usage pain points.

[kris-jusiak]

Thank you very much @phelter, really appreciate actual usage feedback. Need to think a bit more about use cases and how to make generic solution for the library, but that's extremely helpful.