Realization technology __c++ based on C + + finite state machine

--> one. Introduction statement

Finite state machine (FEM) is a tool used for modeling object behavior, which mainly describes the state sequence that an object experiences in its lifecycle and how to respond to various events from outside. In object-oriented software systems, an object, no matter how simple or complex, is bound to undergo a complete process from the beginning to the final extinction, which is often referred to as the object's lifecycle. In general, an object cannot be completely isolated during its lifetime, it must affect other objects by sending messages, or change itself by accepting messages. In most cases, these messages are just simple, synchronized method calls. For example, in a bank account management system, instances of customer classes (customers) may invoke the GetBalance () method defined in the account class when needed. In this simple case, the class customer does not need a finite state machine to describe its behavior, mainly because its current behavior does not depend on a state of the past. [1]

Unfortunately not all of this is so simple, in fact, many practical software systems must maintain one or two very critical objects, they usually have very complex state transition relationships, and need to respond to various asynchronous events from outside. For example, in VoIP telephony systems, instances of a telephony class (telephone) must be able to respond to random calls from each other, keystroke events from the user, and signaling from the network. When processing these messages, the behavior of the class telephone depends entirely on the state in which it is currently located, so it is a good choice to use the state machine at this time. [1]

Game engine is one of the most successful applications of finite state machines, because a well-designed state machine can be used to replace part of the AI algorithm, so every character or device in the game has the potential to embed a state machine. Consider the gate in RPG games such a simple object, it has open (opened), Closed (Closed), Locked (Locked), unlock (unlocked) four states, as shown in Figure 1. When the player arrives at a state-locked door, if he has found the key to open the door, he can use the current state of the door to turn into unlocked and, further, turn its state into a opened by rotating the handle on the doorknob, thereby successfully entering the city. [1]

Fig. 1 state machine for controlling gates

In describing finite state machines, states, events, transformations, and actions are some of the basic concepts that are often encountered.

Status ( State refers to a condition in which an object is in its lifecycle, and an object in a particular state is bound to meet certain conditions, perform certain actions, or wait for certain events.

Events ( Event refers to those things that occupy a certain position in time and space and are meaningful to the state machine. Events usually cause changes in state, prompting the state machine to switch from one state to another.

conversion ( Transition refers to a relationship between two states, indicating that the object will perform a certain action in the first State and will enter the second state when a particular condition is met when an event occurs.

Action refers to those atomic operations that can be performed in a state machine, which means that they cannot be interrupted by other messages while they are running, and must continue to execute. implementation technology of FSM based on traditional C language

2.1, based on the switch (state) implementation

Using a switch statement is the simplest and most straightforward way to implement a finite state, and the basic idea is to set up a case branch for each state in the state machine, specifically to control the state. The following code demonstrates how to use a switch statement to implement the state machine shown in Figure 1:

Switch (state) { Handling branches of state opened Case (opened): { Execute action Open Open (); Check to see if there are any Closedoor events Current state transition to Closed Changestate (Closed) } Break } Handling branches of state closed Case (Closed): { Perform action close Close (); Check to see if there are any Opendoor events if (Opendoor ()) { Current state transition to opened Changestate (opened); } Check to see if there are any Lockdoor events if (Lockdoor ()) { Current state transition to locked Changestate (Locked); } Break } Handling branches of state locked Case (Locked): { Perform action lock Lock (); Check to see if there are any Unlockdoor events if (Unlockdoor ()) { Current state transition to unlocked Changestate (unlocked); } Break } Handling branches of State unlocked Case (Unlocked): { Perform action unlock Unlock (); Check to see if there are any Lockdoor events if (Lockdoor ()) { Changestate (Locked) } if (Opendoor ()) { Current state transition to opened Changesate (opened); } Break } }

A finite state machine implemented with a switch statement does work well, but the readability of the code is not very good, mainly because when you implement transitions between States, checking the transition conditions and making state transitions are mixed in the current state. For example, when a gate is in a opened state, the Closedoor () function needs to be called in the appropriate case to check for state transitions and, if so, to call the Changestate () function to switch the current state to closed. Obviously, if you need to check a number of different conversion conditions in each state, and you need to switch the state machine to a different state based on the results of the check, the code will be tedious and difficult to understand. From the point of view of code refactoring, it is better to introduce Checkstatechange () and Performstatechange () two functions, which are specifically used to check the transformation conditions and the various actions that are required to activate the transformation. As a result, the structure of the program becomes clearer:

switch (state)   {    /Processing Branch of state opened   case (opened): {    //Execute action open     Open ();    /Check for events that trigger state transitions     if (Checkstatechange ()) {      //conversion state of State machine       Performstatechange ();    }     break;  }   //processing Closed for status   case (Closed): {     Execute the action close     close ();    /Check for events that trigger state transitions