{"id":7894,"date":"2019-09-23T10:15:19","date_gmt":"2019-09-23T08:15:19","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=7894"},"modified":"2023-09-29T10:28:33","modified_gmt":"2023-09-29T08:28:33","slug":"implementing-a-state-machine-in-c17-part-2","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/en\/implementing-a-state-machine-in-c17-part-2\/","title":{"rendered":"Implementing a State Machine in C++17 – part 2"},"content":{"rendered":"\n

In my previous article<\/a> we’ve talked about implementing a simple state machine based on a std::variant<\/strong> and other newer additions to the C++ standard. Even though the implementation had its merits it was far from being complete. In this article, we improve upon that design to make it more useful and easy to use. <\/p>\n\n\n\n

If you haven’t read the first part, I highly recommend that you do before diving into this article, as it heavily relies on code examples presented there.<\/p>\n\n\n\n

A problem to solve<\/h2>\n\n\n\n

Let’s start with defining a problem that’ll serve as a testbed for new ideas. Previously a state machine representing basic door was used as an example. Sadly, a door that anyone can open is not very useful, so let’s change that. Let’s introduce a new state locked,<\/strong> so that only someone who knows the key could open the door. A sequence diagram for such state machine could look like this:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Besides an additional state, we’ve introduced two new events lock<\/strong> and unlock<\/strong>. Now, once the door is locked, the only way to open it, is to unlock it first. With all that in mind, we can try to implement such a state.<\/p>\n\n\n

\nstruct LockedState\n{\nNothing      handle(const OpenEvent&)   const { return {}; }\nNothing      handle(const CloseEvent&)  const { return {}; }\nNothing      handle(const LockEvent&)   const { return {}; }\nTransitionTo handle(const UnlockEvent&) const { return {}; }\n};\n<\/pre><\/div>\n\n\n
Now, that’s a lot of boilerplate code! The state reacts only on unlock<\/strong> event but we had to provide actions for all 4 events. To make it even worse, we need to implement handlers for those two newly added events in closed<\/strong> and open<\/strong> states. To fix this, let’s provide a mechanism to collapse all similar event handlers.<\/p>\n\n\n
\ntemplate <typename Action>\nstruct ByDefault\n{\ntemplate <typename Event>\nAction handle(const Event&) const\n{\nreturn Action{};\n}\n};\n<\/pre><\/div>\n\n\n
We can use this struct as a base for some of our states introducing some common behavior. Why is the action type parametrized you might ask? That’s because sometimes there’s a better action to invoke other than Nothing<\/strong>, like for example TransitionTo<\/strong>. Let’s see how this improves things when applied to closed<\/strong> state.<\/p>\n\n\n
\nstruct ClosedState : ByDefault<Nothing>\n{\nusing ByDefault::handle;\n \nTransitionTo<LockedState> handle(const LockEvent&) const { return {}; }\nTransitionTo<OpenState>   handle(const OpenEvent&) const { return {}; }\n};\n<\/pre><\/div>\n\n\n
Better! But still not perfect \ud83d\ude42 First of all, as we have handle<\/strong> method overloaded in ClosedState<\/strong>, we need to pull handle<\/strong> from ByDefault<\/strong> base class with a using<\/strong> declaration. Additionally, handlers for LockEvent<\/strong> and OpenEvent<\/strong> don’t do anything except returning a default constructed action object. This behavior could be shared in a helper base structure.<\/p>\n\n\n
\ntemplate <typename Event, typename Action>\nstruct On\n{\nAction handle(const Event&) const\n{\nreturn {};\n}\n};\n<\/pre><\/div>\n\n
\nstruct ClosedState : ByDefault<Nothing>,\nOn<LockEvent, TransitionTo<LockedState>>,\nOn<OpenEvent, TransitionTo<OpenState>>\n{\nusing ByDefault::handle;\nusing On<LockEvent, TransitionTo<LockedState>>::handle;\nusing On<OpenEvent, TransitionTo<OpenState>>::handle;\n};\n<\/pre><\/div>\n\n\n
<\/openevent,><\/lockevent,><\/openevent,><\/lockevent,><\/p>\n\n\n\n
Not much of an improvement since we still need to pull in handlers from all base classes. Fortunately, there’s a way to circumvent it. C++17 allows expanding parameter packs inside using<\/strong> declarations. We can use it to pull all overloads into a single base class.<\/p>\n\n\n
\ntemplate <typename... Handlers>\nstruct Will : Handlers...\n{\nusing Handlers::handle...;\n};\n<\/pre><\/div>\n\n\n
Now we can get rid of all those using<\/strong> declarations.<\/p>\n\n\n
\nstruct ClosedState : public Will&lt;ByDefault&lt;Nothing>,\nOn&lt;LockEvent, TransitionTo&lt;LockedState>>,\nOn&lt;OpenEvent, TransitionTo&lt;OpenState>>>\n{\n};\n<\/pre><\/div>\n\n\n
Now, that’s much better \ud83d\ude42 But our work is still far from complete. Even though we introduced a new locked<\/strong> state, we still don’t do any kind of verification. First of all, we need to store some value, let’s call it ‘key’, inside the state, which will be later used for access control. The issue here is that the states are currently default initialized by the state machine. We need to add a way to construct the states outside the state machine and pass them to the state machine constructor.<\/p>\n\n\n
\nStateMachine(States... states) : states(std::move(states)...) { }\n \nStateMachine() = default;\n \nStateMachine(States... states)\n: states(std::move(states)...)\n{\n}\n<\/pre><\/div>\n\n\n
In essence, when we’re in a locked<\/strong> state we should only accept unlock<\/strong> events that have a matching ‘key’. This poses a problem since actions are returned from state handle<\/strong> methods and can have only one return type. We need to model somehow a situation where the result of an event can be an alternative to many possibilities. We can utilize std::variant<\/strong> for this task.<\/p>\n\n\n
\ntemplate <typename... Actions>\nclass OneOf\n{\npublic:\ntemplate <typename T>\nOneOf(T&& arg)\n: options(std::forward<T>(arg))\n{\n}\n \ntemplate <typename Machine>\nvoid execute(Machine& machine)\n{\nstd::visit([&machine](auto& action){ action.execute(machine); }, options);\n}\n \nprivate:\nstd::variant<Actions...> options;\n};\n<\/pre><\/div>\n\n\n
And since, most of the time, we want to either do one thing or do nothing at all, as a convenience, another helper type can be introduced.<\/p>\n\n\n
\ntemplate <typename Action>\nstruct Maybe : public OneOf<Action, Nothing>\n{\nusing OneOf<Action, Nothing>::OneOf;\n};\n<\/pre><\/div>\n\n\n
Now, with that in place, we can update both the unlock<\/strong> event and locked<\/strong> state<\/p>\n\n\n
\nstruct UnlockEvent\n{\nuint32_t key;\n};\n \nclass LockedState : public ByDefault<Nothing>\n{\npublic:\nusing ByDefault::handle;\n \nLockedState(uint32_t key)\n: key(key)\n{\n}\n \nMaybe<TransitionTo<ClosedState>> handle(const UnlockEvent& e) const\n{\nif (e.key == key) {\nreturn TransitionTo<ClosedState>{};\n}\nreturn Nothing{};\n}\n \nprivate:\nuint32_t key;\n};\n<\/pre><\/div>\n\n\n
Great! That’s exactly what we wanted! We’ve defined a state machine that resembles a door that can be unlocked only when the passed key matches the one stored in the state.<\/p>\n\n\n\n
Taking things further<\/h2>\n\n\n\n
What if we wanted to model some kind of programmable door. Like a safe in some hotels, where you can define your own pin code, but you can do that only when the safe is unlocked. A sequence diagram for such door could look like this:<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
<\/div>\n\n\n\n
Locking and unlocking<\/h2>\n\n\n\n
Let’s start by adding a ‘newKey’ field to l<\/strong>ock<\/strong> event. That’s not a big problem. The biggest hurdle is how to inform locked<\/strong> state about that new value? We could, for example, define a new action type that would update a given state. Even though that would solve our problem, it’s not the best solution, since it requires closed<\/strong> state to know the internals of a completely different state – locked<\/strong>.<\/p>\n\n\n\n
The true problem that we need to solve lies even deeper. Instead of trying to pass this information from one state to another, we should focus on giving the state information when it was entered and under what circumstances. For example, we could use this information to open a socket or maintain a database connection for as long as we’re in that state and tear down everything once we leave.<\/p>\n\n\n\n
Necessary changes<\/h2>\n\n\n\n
To start, we need to provide a bit more information to the actions. To call appropriate methods, TransitionTo<\/strong> action would need to know what’s the current state and what event triggered the action. Apart from that, we want to grab a reference to the newly selected state when we make a transition. Let’s update our state machine’s implementation to provide that extra information.<\/p>\n\n\n
\ntemplate <typename Event>\nvoid handle(const Event& event)\n{\nauto passEventToState = [this, &event] (auto statePtr) {\nauto action = statePtr->handle(event);\naction.execute(*this, *statePtr, event);\n};\nstd::visit(passEventToState, currentState);\n}\n \ntemplate <typename State>\nState& transitionTo()\n{\nauto& state = std::get<State>(states);\ncurrentState = &state;\nreturn state;\n}\n<\/pre><\/div>\n\n\n
Now let’s update the TransitionTo<\/strong> action. We want to call onLeave<\/strong> method the on previous state and onEnter<\/strong> on the destination state, but how do we know that these methods are present? We could enforce it, just like it’s done with handle<\/strong> methods, but that would lead to a lot of unnecessary code. We can use SFINAE<\/strong> (link<\/a>) to detect if such a method exists. If it does, we’ll call it, if not, we’ll simply ignore it.<\/p>\n\n\n\n
You may ask why we didn’t use that trick with handle<\/strong> methods and implemented a bunch of helpers just to provide some default behavior? That’s because the situation is a little bit different. Formally speaking, a transition function should be defined for each state and each event. Furthermore, there are situations when we want to trigger a compilation error when we add a new event and one of the existing states doesn’t know how to handle it, instead of blindly ignoring it. With that in mind, let’s update the TransitionTo<\/strong> action.<\/p>\n\n\n
\ntemplate <typename TargetState>\nclass TransitionTo\n{\npublic:\ntemplate <typename Machine, typename State, typename Event>\nvoid execute(Machine& machine, State& prevState, const Event& event)\n{\nleave(prevState, event);\nTargetState& newState = machine.template transitionTo<TargetState>();\nenter(newState, event);\n}\n \nprivate:\nvoid leave(...)\n{\n}\n \ntemplate <typename State, typename Event>\nauto leave(State& state, const Event& event) -> decltype(state.onLeave(event))\n{\nreturn state.onLeave(event);\n}\n \nvoid enter(...)\n{\n}\n \ntemplate <typename State, typename Event>\nauto enter(State& state, const Event& event) -> decltype(state.onEnter(event))\n{\nreturn state.onEnter(event);\n}\n};\n<\/pre><\/div>\n\n\n
Thanks to SFINAE<\/strong>, we can detect if a onEnter<\/strong> or onLeave<\/strong> method was defined and act accordingly. The last thing to do is to implement an onEnter<\/strong> method for locked<\/strong> state<\/p>\n\n\n
\nvoid onEnter(const LockEvent& e)\n{\nkey = e.newKey;\n}\n<\/pre><\/div>\n\n\n
Wrapping things up<\/h2>\n\n\n\n
In this article, we explored how previous state machine implementation could be enhanced in order to support optional transitions and how to make it easier to use. States can now define custom onEnter<\/strong> and onLeave <\/strong>methods that will be called when the state is entered or left. If you want to play with that code, you can grab it here<\/a>.<\/p>\n\n\n\n
In the next part of the article, we’ll play with adding support for tracing and debugging information and we’ll try to infer a nice transition table solely based on the StateMachine’s type, so stay tuned! \ud83d\ude42<\/p>\n\n\n
\n            \n
\n    \n
\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n    <\/div>\n    \n
\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n    <\/div>\n<\/div>\n                \n\n
\n            4.3\/5 ( votes: 20)    <\/div>\n    <\/div>\n","protected":false},"excerpt":{"rendered":"
In my previous article we’ve talked about implementing a simple state machine based on a std::variant and other newer additions … Continued<\/a><\/p>\n","protected":false},"author":193,"featured_media":8172,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_editorskit_title_hidden":false,"_editorskit_reading_time":0,"_editorskit_is_block_options_detached":false,"_editorskit_block_options_position":"{}","inline_featured_image":false,"footnotes":""},"categories":[1320],"tags":[1425,1395,1375,1427,1430],"class_list":["post-7894","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hard-development","tag-c-en","tag-c17-en","tag-embedded-competency-center-en","tag-state-machine-en","tag-stdvariant-en"],"acf":[],"aioseo_notices":[],"republish_history":[],"featured_media_url":"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2019\/08\/code-coding-conceptual-270360.jpg","category_names":["Hard development"],"_links":{"self":[{"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/posts\/7894"}],"collection":[{"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/users\/193"}],"replies":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/comments?post=7894"}],"version-history":[{"count":2,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/posts\/7894\/revisions"}],"predecessor-version":[{"id":24556,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/posts\/7894\/revisions\/24556"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/media\/8172"}],"wp:attachment":[{"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/media?parent=7894"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/categories?post=7894"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/tags?post=7894"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}