{"id":18,"date":"2023-12-12T08:01:00","date_gmt":"2023-12-12T07:01:00","guid":{"rendered":"https:\/\/sii.ua\/blog\/?p=18"},"modified":"2024-02-16T09:45:34","modified_gmt":"2024-02-16T08:45:34","slug":"implementing-a-state-machine-in-c17","status":"publish","type":"post","link":"https:\/\/sii.ua\/blog\/en\/implementing-a-state-machine-in-c17\/","title":{"rendered":"Implementing a State Machine in C++17"},"content":{"rendered":"\n
Finite State Machines are a very useful concept that allows modeling complex behavior. The basic idea is quite simple. We have a set of possible states and we define rules that govern transitions between the current state and some other state upon receiving an event. So how to implement one in C++17? Of course, there is a multitude of ways to do it. In this article, we try to explore another possibility based on several newer additions to the C++ standard.<\/p>\n\n\n\n
Let\u2019s build a State Machine<\/h2>\n\n\n\n
So what\u2019s a state anyway? In reality, it can be anything. For the sake of this article let’s just assume that’s an arbitrary object. That object’s type can be used to distinguish it from other states. This way we don\u2019t have to maintain a separate list of all possible states (like an enumeration for example). Furthermore, we don\u2019t want to enforce any form of relationship between those types to keep them as separate as possible. So how to pass and store those completely independent types? A variadic template containing a std::tuple (both introduced in C++11) can help us with that.<\/p>\n\n\n
There are a few noteworthy things about this class. First of all, StateMachine has no prior information about the states it contains. Additionally, we don’t have to worry about their lifetime as it\u2019s tied to the lifetime of the machine itself.<\/p>\n\n\n\n
Next on our todo list is to keep track which state is currently selected. Normally a plain pointer or a reference would suffice, but that\u2019s not going to work in this case, because it\u2019s impossible to select a single type that would accept all possible state types (besides void*, but that would be useless for us). As we’re trying to store heterogeneous data types we can use the std::variant (C++17) for that task. Since std::variant disallows using it with references, we have to use plain pointers. Additionally, we assume that the first state type provided to the state machine is the initial state.<\/p>\n\n\n
Now is time to add a method to change the current state of the machine. Once again, since we distinguish states by their type, it has to be a template method.<\/p>\n\n\n
So far so good. Now we need to pass event information to the machine. That raises a fundamental question – what kind of events do we want to handle? As the states are doing the actual work let\u2019s simply pass the event to the current state and let it handle it. In other words, the machine is able to accept all events that its states are capable of handling.<\/p>\n\n\n
This change introduced a dependency on the type of state. Each time an event of type T is handled by the machine, the compiler ensures that all the state types have a \u2018handle\u2019 method that accepts an event of type T.<\/p>\n\n\n\n
The last thing that’s missing is the ability to transition to another state based on the passed event. We need to figure out how to instruct the machine to perform a transition while being inside an event handler in a given state. There are some obstacles though. We don’t want to pass the machine type to the states, because we don’t want to tie them together. To fix this issue let\u2019s return an intermediate object from the state’s ‘handle’ method that will describe what action should the machine take.<\/p>\n\n\n
Formally speaking, after receiving an event a machine should always transition to some state, even if it\u2019s the same state as current. On the other hand, there are situations when we want to ignore an event and skip performing any action on the machine. To model this kind of behaviour we introduce a new action type.<\/p>\n\n\n
Assuming we have some state Foo and we want to switch to state Bar on Trigger<\/em> event and do nothing on Ignored<\/em> event, the state\u2019s implementation could look like this:<\/p>\n\n\n
\nstruct Foo\n{\nTransitionTo<Bar> handle(const Trigger& event)\n{\n\/* some important calculations etc. *\/\nreturn {};\n}\n \nNothing handle(const Ignored&)\n{\nreturn {};\n}\n};\n<\/pre><\/div>\n\n\n
Example<\/h2>\n\n\n\n
Let’s see how it all works together by implementing a simple state machine representing a door. There are two states (Closed and Open) and two events (Open, Close). This is how the transition diagram looks like:<\/p>\n\n\n\n<\/figure>\n\n\n
![\"\"](\"https:\/\/sii.ua\/blog\/wp-content\/uploads\/2023\/12\/12-1.png\")
<\/figure>\n\n\n