State machines don't have syntax for "transition here when event is encountered no matter what state you are in" so the whole diagram becomes a spaghetti mess if you have a lot of those escape hatches.

▲

lelanthran 10 months ago | parent | next [-]

> State machines don't have syntax for "transition here when event is encountered no matter what state you are in" so the whole diagram becomes a spaghetti mess if you have a lot of those escape hatches.

I place a note at the top of my diagrams stating what the default state would be on receipt of an unexpected event. There is no such thing as "event silently gets swallowed because no transition exists", because, in implementation, the state machine `switch` statement always has a `default` clause which triggers all the alarm bells.

Works very well in practice; I used to write hard real-time munitions control software for blowing shit up. Never had a problem.

▲

rramadass 10 months ago | parent [-]

> hard real-time munitions control software for blowing shit up. Never had a problem.

Ha, Ha, Ha! The juxtaposition of these two phrases is really funny. I would like to apply for a position on the Testing team :-)

	▲	lelanthran 10 months ago \| parent [-]
		> Ha, Ha, Ha! The juxtaposition of these two phrases is really funny. I would like to apply for a position on the Testing team :-) It had its moments: used to go to a range where we'd set off detonators. Once or twice in production on site where we'd set off actual explosives.

▲

quietbritishjim 10 months ago | parent | prev | next [-]

State machines don't have a native syntax in C++ at all, so you can structure them however you want. It's easy to structure a state machine, if needed, so that all (or some) states can handle the same event in the same way.

▲

dgfitz 10 months ago | parent | next [-]

I always thought this framework was neat: https://doc.qt.io/qt-5/statemachine-api.html

Downside of course is now you have a dependency on qt.

▲

alexvitkov 10 months ago | parent [-]

The downside is that you're now heap allocating at least one object for every state, and I'm willing to bet that each QState has an associated std::vector-style list of actions, and that each action is also its own object on the heap.

If you can afford to do things like this you can most likely use something other than C++ and save yourself a lot of headaches.

	▲	dgfitz 10 months ago \| parent [-]
		> If you can afford to do things like this you can most likely use something other than C++ and save yourself a lot of headaches. Surely you can understand that, despite the recent c++ hate, my job doesn't give a fuck and we aren't migrating our massive codebase from c++ to... anything.

▲

garethrowlands 10 months ago | parent | prev [-]

Switch + goto is very close to being a native syntax for state machines. It's also very efficient.

▲

liontwist 10 months ago | parent | prev | next [-]

goto is exactly this feature.

▲

a_t48 10 months ago | parent | prev [-]

I believe HSMs can model this, but don't quote me. :)

▲

nurettin 10 months ago | parent [-]

Yes, of course in theory nested state machines should be able to model this. I feel like adding more complexity and bending the rules is a bit of a concession.

	▲	jeffreygoesto 10 months ago \| parent [-]
		Back in the days we implemented HSM helper classes in about 500 LoC and generated them from Enterprise Architect. No need to write a GUI yourself, but better to have a visual for documentation and review. Worked very well until we replaced EA with docs-as-code, now I miss that there is no nice simulator and Modeler for that workflow.