[Copy to clipboard] [ - ]

CODE:

int atoi( char *str )
{
char *p = str;
int cs, val = 0;
bool neg = false;

%%{       //Ragel 的关键字,用于声明状态机代码段的开始
  action see_neg {
   neg = true;
  }

  action add_digit {
   val = val * 10 + (fc - '0');
  }

  main :=
   ( '-'@see_neg | '+' )? ( digit @add_digit )+
   '\n' @{ fbreak; };

  # Initialize and execute.
  write init;                                  //状态机关键字,这个会再接下来的内容中介绍
  write exec noend;                     //同上
}%%                                        //状态机代码段结束标记

if ( neg )
  val = -1 * val;

if ( cs < atoi_first_final )
  cerr << "atoi: there was an error" << endl;

return val;
};

比c里面那500多行实现的atoi函数更加高效

上面这段代码，生成的C语言代码如下:

[Copy to clipboard] [ - ]

CODE:

int atoi( char *str )
{
char *p = str;
int cs, val = 0;
bool neg = false;

#line 27 "atoi.c"
{
cs = atoi_start;
}

#line 31 "atoi.c"
{
switch ( cs )
{
case 1:
switch( (*p) ) {
  case 43: goto st2;
  case 45: goto tr2;
}
if ( 48 <= (*p) && (*p) <= 57 )
  goto tr3;
goto st0;
st0:
goto _out0;
tr2:
#line 23 "atoi.rl"
{
   neg = true;
  }
goto st2;
st2:
p += 1;
case 2:
#line 52 "atoi.c"
if ( 48 <= (*p) && (*p) <= 57 )
  goto tr3;
goto st0;
tr3:
#line 27 "atoi.rl"
{
   val = val * 10 + ((*p) - '0');
  }
goto st3;
st3:
p += 1;
case 3:
#line 63 "atoi.c"
if ( (*p) == 10 )
  goto tr4;
if ( 48 <= (*p) && (*p) <= 57 )
  goto tr3;
goto st0;
tr4:
#line 33 "atoi.rl"
{ goto _out4; }
goto st4;
st4:
p += 1;
case 4:
#line 74 "atoi.c"
goto st0;
}
_out0: cs = 0; goto _out;
_out4: cs = 4; goto _out;

_out: {}
}
#line 38 "atoi.rl"


if ( neg )
  val = -1 * val;

if ( cs < atoi_first_final )
  cerr << "atoi: there was an error" << endl;

return val;
};

对应的状态图如下图所示:

  看看小时候玩的5块钱那种最简单的电子表。只有2个按钮就能操作(暂且称为按钮A和按钮B)。
  现给出一个完整的功能文字描述：
     在显示时间时按A，屏幕显示变成日期
     在显示日期时按A，屏幕显示变成秒钟
     在显示秒钟时按A，屏幕显示变成时间
     在显示秒钟时按B，秒钟归0
     在显示时间时按B，屏幕 时间、日期交替显示。
     在时间、日期交替显示时按B，屏幕“时”闪烁
     在“时”闪烁时按B，屏幕“时”加1，超过23回0
     在“时”闪烁时按A，屏幕“分”闪烁
     在“分”闪烁时按B，屏幕“分”加1，超过59回0
     在“分”闪烁时按A，屏幕“月”闪烁
     在“月”闪烁时按B，屏幕“月”加1，超过12回0
     在“月”闪烁时按A，屏幕“日”闪烁
     在“日”闪烁时按B，屏幕“日”加1，超过31回0
     在“日”闪烁时按A，屏幕回到时间显示

    如果按照新手的思路，尝试去画流程图，很快就会陷入一头雾水：你会发现实现这个功能的程序根本就没有“确定的流程”。因为程序实际流程是根据人的操作而变化的。程序运行到什么地方，完全取决于两个键的次序，有无数种次序组合，根本不可能画出流程图来。
    但是我们会发现，这个电子表功能的“语言描述”在语法上似乎有某种规律，就是：
    当系统处于某状态（S1）时，如果发生了什么事情(E)，就执行某功能(F)，然后系统变成新状态（S2）
    只要能用上面这句话描述的系统，都可以用一种状态跳转机制很方便的实现
，并且一句话其实就是一个if(...)，无论有多少多复杂的功能，只要能用上面这句话描述，都可以通过状态机编程实现。  
  
我们将它们抽象。整个系统中有2个事件分别是：A按下，B按下

    A按下(可以是中断)时执行：
{
     if(Status==TIME)  //当显示时间时按下A键
     {
        Status=DATE    //变成显示日期
     }
     if(Status==DATE)  //当显示日期时按下A键
     {
        Status=SEC     //变成显示秒钟
     }
     if(Status==SEC)  //当显示秒钟时按下A键
     {
        Status=TIME     //变成显示时间
     }
     if(Status==SET_HOUR)  //当设置“小时”时按下A键
     {
        Status=SET_MINUT        //变成设置“分钟”
     }
     if(Status==SET_MINUT)  //当设置“分钟”时按下A键
     {
        Status=SET_MONTH        //变成设置“月”
     }
     .....
     .....
}
 

    B按下(可以是中断)时执行：
{
      if(Status==SEC)  //当显示秒钟时按下B键
     {
        Secound=0     //秒归0
     }
     if(Status==TIME)  //当显示时间时按下B键
     {
        Status=TIMEDATE    //变成时间日期交替显示
     }
     if(Status==TIMEDATE)  //当日期交替显示时按下B键
     {
        Status=SET_HOUR    //变成设置“时”（时闪烁）
     }
     if(Status==SET_HOUR)  //当设置“时”时按下B键
     {
        Status=Hour++      //时加1
        if(Hour>23) Hour="0";     
     }

     .....
     .....       
}

     和语言描述完全一致，很快就能写完程序。这就是最简单的状态机思想。
     当然，上述一大堆if可以用switch case来实现
     实际中，大量的并发过程都可以表述为状态跳转关系，从而将CPU从过程中解放出来，只需处理状态关系，因为真正需要CPU的是状态变化的时刻，而不是过程中大量的等待，这样大量的并发过程都可以并行处理。

有限状态机（以下用FSM指代）是一种算法思想，简单而言，有限状态机由一组状态、一个初始状态、输入和根据输入及现有状态转换为下一个状态的转换函数组成。在Gof的23种设计模式里的state模式是一种面向对象的状态机思想，可以适应非常复杂的状态管理。
现 在，FSM被普遍用于搜索引擎的分词、编译器实现和我们普遍关注的游戏开发中。游戏开发中，通常用FSM实现NPC控制，如当NPC受到攻击时根据健康、力量等选择逃跑还是反攻的行为，一般是用FSM实现的。FSM的实现方法有很多种，不能简单地说孰优孰劣，但现代开发中，一般都比较推荐面向对象的实现方式：因为可重用性和健壮性更高，而且当需求变更的时候，也有很好的适应性。
实践
理 论从实践中来，也要回到实践中去。我们现在通过实例来探索一下FSM的实现吧。首先假设有这样一个世界（World），世界里只有一台永不缺乏动力的汽车 （Car），汽车是次世代的，没有油门方向盘之类的落后设备，只有两个互斥的按钮——停止（Stop）和行进（Run），随着时间的流逝，汽车根据驾驶员的操作走走停停。下面的代码可以实现这种功能：
       while True:
       key = get_key() # 按下什么键
       if key == "stop":
              stop(car)
       elif key == "run":
              go(car)
       keep(car) # 保持原态  

完 成了功能而且直观、简洁的程序员万岁！但这时候客户（策划或者玩家）觉得走走停停太没意思了，他们想要掉头、左转和右转的功能，我们就要在while循环 里增加更多的if...else分支；他们想要更多的车，我们就要要在每一个分枝里增加循环；他们不仅仅想要Car了，他们还要要玩Truck，这时我们 就需要在分枝的循环里判断当前的车是否支持这个操作（如Truck的装卸货物Car就不支持）；他们……
这个while循环终于无限地庞大起来，我们认识到这样的设计的确是有点问题的，所以我们尝试用另一种方法去实现FSM。首先我们来实现汽车（Car）：
       class Car(object):
       def stop(self):
              print "Stop!!!"
       def go(self):
              print "Goooooo!!!" 

只有两个方法stop和go，分别执行Stop和Run两个按钮功能。接下来我们编写两个状态管理的类，用以处理当按钮被按下、弹起和保持时需要工作的流程：
class stop_fsm(base_fsm):
       def enter_state(self, obj):
              print "Car%s enter stop state!"%(id(obj))
 
       def exec_state(self, obj):
              print "Car%s in stop state!"%(id(obj))
              obj.stop()
 
       def exit_state(self, obj):
              print "Car%s exit stop state!"%(id(obj)) 
class run_fsm(base_fsm):
       def enter_state(self, obj):
              print "Car%s enter run state!"%(id(obj))
 
       def exec_state(self, obj):
              print "Car%s in run state!"%(id(obj))
              obj.go()
 
       def exit_state(self, obj):
              print "Car%s exit run state!"%(id(obj)) 

stop_fsm和run_fsm都继承自base_fsm，base_fsm是一个纯虚的接口类：
class base_fsm(object):
       def enter_state(self, obj):
              raise NotImplementedError()
 
       def exec_state(self, obj):
              raise NotImplementedError()
 
       def exit_state(self, obj):
              raise NotImplementedError() 

enter_state 在obj进入某状态的时候调用——通常用来做一些初始化工作；exit_state也离开某状态的时候调用——通常做一些清理工作；而 exec_state则在每一帧的时候都会被调用，通常做一些必要的工作，如检测自己的消息队列并处理消息等。在stop_fsm和run_fsm两个类 的exec_state函数中，就调用了对象的stop和go函数，让汽车保持原有的状态。
至现在为止，Car还没有接触到FSM，所以我们需要提供一个接口，可以让它拥有一个FSM：
       def attach_fsm(self, state, fsm):
              self.fsm = fsm
              self.curr_state = state 

我们还需要为Car提供一个状态转换函数：
       def change_state(self, new_state, new_fsm):
              self.curr_state = new_state
              self.fsm.exit_state(self)
              self.fsm = new_fsm
              self.fsm.enter_state(self)
              self.fsm.exec_state(self) 

为Car提供一个保持状态的函数：
       def keep_state(self):
              self.fsm.exec_state(self) 

现在只有两个状态，但我们知道需求随时会改动，所以我们最好弄一个状态机管理器来管理这些状态：
class fsm_mgr(object):
       def __init__(self):
              self._fsms = {}
              self._fsms[0] = stop_fsm()
              self._fsms[1] = run_fsm()
      
       def get_fsm(self, state):
              return self._fsms[state]
      
       def frame(self, objs, state):
              for obj in objs:
                     if state == obj.curr_state:
                            obj.keep_state()
                     else:
                            obj.change_state(state, self._fsms[state]) 

fsm_mgr最重要的函数就是frame，在每一帧都被调用。在这里，frame根据对象现在的状态和当前的输入决定让对象保持状态或者改变状态。
这时候，我们的实例基本上完成了。但我们还要做一件事，就是建立一个世界（World）来驱动状态机：
class World(object):
       def init(self):
              self._cars = []
              self._fsm_mgr = fsm_mgr()
              self.__init_car()
 
       def __init_car(self):
              for i in xrange(1):   # 生产汽车
                     tmp = Car()
                     tmp.attach_fsm(0, self._fsm_mgr.get_fsm(0))
                     self._cars.append(tmp)
 
       def __frame(self):
              self._fsm_mgr.frame(self._cars, state_factory())
 
       def run(self):
              while True:
                     self.__frame()
                     sleep(0.5) 

从 代码可见，World里有Car对象，fsm_mgr对象；在run函数里，每0.5s执行一次__frame函数（FPS = 2），而__frame函数只是驱动了fsm_mgr来刷新对象，新的命令是从state_factory函数里取出来的，这个函数用以模拟驾驶员的操作（按下Stop或者Run按钮之一）：
def state_factory():
       return random.randint(0, 1) 

现在我们就要初始化世界（World）可以跑起我们的FSM了！
if __name__ == "__main__":
       world = World()
       world.init()
       world.run() 

用python解释器执行上面的代码，我们可以看到程序不停地输出Car的状态：
......
Car8453392 exit run state!
Car8453392 enter stop state!
Car8453392 in stop state!
Stop!!!
Car8453392 in stop state!
Stop!!!
Car8453392 exit stop state!
Car8453392 enter run state!
Car8453392 in run state!
Goooooo!!!
Car8453392 exit run state!
Car8453392 enter stop state!
Car8453392 in stop state!
Stop!!!
Car8453392 exit stop state!
Car8453392 enter run state!
Car8453392 in run state!
Goooooo!!!
Car8453392 in run state!
Goooooo!!!
Car8453392 exit run state!
Car8453392 enter stop state!
Car8453392 in stop state!
Stop!!!
Car8453392 in stop state!
Stop!!!
Car8453392 exit stop state!
Car8453392 enter run state!
Car8453392 in run state!
Goooooo!!!
...... 

 
结论
这时再回头来看看我们之前的问题：
1、玩家想要功能更多的Car，比如掉头。
我 们可以通过为Car增加一个调头（back）的方法来执行掉头，然后从base_fsm中继承一个back_fsm来处理调头。之后在fsm_mgr里增 加一个back_fsm实例，及让state_factory产生调头指令。听起来似乎比之前while+if的方式还要麻烦不少，其实不然，这里只有 back_fsm和为fsm_mgr增加back_fsm实例才是特有的，其它步骤两种方法都要执行。
2、玩家要更多的Car。
这对于面向对象的FSM实现就太简单了，我们只要把World.__init_car里的生产数量修改一下就行了，要多少有多少。
3、玩家要更多型号的车，如Truck。
从Car派生一个Truck，然后增加装货、卸货的接口。最大的改动在于Truck状态转换的时候需要一些判断，如不能直接从装货状态转换到开动状态，而是装货、停止再开动。
通 过这几个简单的问题分析，我们可以看到，使用面向对象的方式来设计FSM，在需求变更的时候，一般都只增删代码，而仍少需要改动已有代码，程序的扩展性、适应性和健壮性都得很大的提高；因此，在世界庞大、物种烦多、状态复杂且条件交错的游戏开发中应用面向对象的FSM实在是明智之选。还有一点，面向对象的 FSM可以非常容易地模拟消息机制，这有利于模块清晰化，更容易设计出正交的程序。

关于状态机的一个极度确切的描述是它是一个有向图形，由一组节点和一组相应的转移函数组成。状态机通过响应一系列事件而“运行”。每个事件都在属于“当前” 节点的转移函数的控制范围内，其中函数的范围是节点的一个子集。函数返回“下一个”（也许是同一个）节点。这些节点中至少有一个必须是终态。当到达终态， 状态机停止。

包含一组状态集（states）、一个起始状态（start state）、一组输入符号集（alphabet）、一个映射输入符号和当前状态到下一状态的转换函数（transition function）的计算模型。当输入符号串，模型随即进入起始状态。它要改变到新的状态，依赖于转换函数。在有限状态机中，会有有许多变量，例如，状态机有很多与动作（actions）转换(Mealy机)或状态（摩尔机）关联的动作，多重起始状态，基于没有输入符号的转换，或者指定符号和状态（非定有 限状态机）的多个转换，指派给接收状态（识别者）的一个或多个状态，等等。

　　传统应用程序的控制流程基本是顺序的：遵循事先设定的逻辑，从头到尾地执行。很少有事件能改变标准执行流程；而且这些事件主要涉及异常情况。“命令行实用程序”是这种传统应用程序的典型例子。

另一类应用程序由外部发生的事件来驱动——换言之，事件在应用程序之外生成，无法由应用程序或程序员来控制。具体需要执行的代码取决于接收到的事件，或者它相对于其他事件的抵达时间。所以，控制流程既不能是顺序的，也不能是事先设定好的，因为它要依赖于外部事件。事件驱动的GUI应用程序是这种应用程序的典型例子，它们由命令和选择（也就是用户造成的事件）来驱动。

Web应用程序由提交的表单和用户请求的网页来驱动，它们也可划归到上述类别。但是，GUI应用程序对于接收到的事件仍有一定程度的控制，因为这些事件要依赖于向用户显示的窗口和控件，而窗口和控件是由程序员控制的。Web应用 程序则不然，因为一旦用户采取不在预料之中的操作（比如使用浏览器的历史记录、手工输入链接以及模拟一次表单提交等等），就很容易打乱设计好的应用程序逻辑。

显然，必须采取不同的技术来处理这些情况。它能处理任何顺序的事件，并能提供有意义的响应——即使这些事件发生的顺序和预计的不同。有限状态机正是为了满足这方面的要求而设计的。

　　有限状态机是一种概念性机器，它能采取某种操作来响应一个外部事件。具体采取的操作不仅能取决于接收到的事件，还能取决于各个事件的相对发生顺序。之所以能做到这一点，是因为机器能跟踪一个内部状态，它会在收到事件后进行更新。为一个事件而响应的行动不仅取决于事件本身，还取决于机器的内部状态。另外，采取 的行动还会决定并更新机器的状态。这样一来，任何逻辑都可建模成一系列事件/状态组合。

有限状态自动机是具有离散输入和输出的系统的一种数学模型。

　　其主要特点有以下几个方面：

– (1)系统具有有限个状态，不同的状态代表不同的意义。按照实际的需要，系统可以在不同的状态下完成规定的任务。

– (2)我们可以将输入字符串中出现的字符汇集在一起构成一个字母表。系统处理的所有字符串都是这个字母表上的字符串。

– (3)系统在任何一个状态下，从输入字符串中读入一个字符，根据当前状态和读入的这个字符转到新的状态。

– (4)系统中有一个状态，它是系统的开始状态。

– (5)系统中还有一些状态表示它到目前为止所读入的字符构成的字符串是语言的一个句子。

–

　　形式定义

• 定义：有限状态自动机(FA—finite automaton)是一个五元组：

– M=(Q, Σ, δ, q0, F)

• 其中，

– Q——状态的非空有穷集合。∀q∈Q，q称为M的一个状态。

– Σ——输入字母表。

– δ——状态转移函数，有时又叫作状态转换函数或者移动函数，δ：Q×Σ→Q，δ(q,a)=p。

– q0——M的开始状态，也可叫作初始状态或启动状态。q0∈Q。

– F——M的终止状态集合。F被Q包含。任给q∈F，q称为M的终止状态。

       显然，后一个状态集是依赖于前一个状态集的，是在前一个状态集的基础上，（其内任意结点）经过同一条路径到达的。下面是一个简单的例子：

可以看出，其核心是将 NFA 状态集归并为 DFA 中的状态。在 NFA 中，无论是从 1 到 4 ，还是 1 到 5 ，作为集合来讲都是集合 1 到集合 2 ，最为重要得是经过的条件都是 a 。因而从识别语言的效果是一样的。这使得这些弧合并成为可能。

考虑集合覆盖的情况。

一个结点属于第一个集合又同时属于第二个集合。这种情况不一定好理解。但如果从路径的历史的角度进一步区分，即不同的时间经过同一个结点，将其看成是不同的状态。按照这种时空的角度进一步区分，得到右图。这和图 1 是类似的。

再来看看带有终态结点的情况：

ab ， abb 均为该 NFA 识别的句子，其转换如下：

从某种意义上说。 NFA 中的状态 3 在 DFA 中被分离成两部分，当首次到达 3 时应该是状态 B ，而第二次以后再到达 3 则应该属于状态 C 。

根据规则， C{3,4} 为 DFA 的终态，但在 NFA 中，只有 4 为终态， C 中仍然有 3 为非终态，若有路径 1 à 3 à 3 映射到 DFA 中也是 A à B à C ，何解？

这里面最关键的是：对任意一个句子，总可以在两个图中分别找到一条路径，形成对应关系。并不是说 NFA 中的每条路径都要和 DFA 中的每条路径一一对应。

当识别句子 ab 时，选择由 3 直接到达 4 的路径。当识别句子 abb 时，则在状态 3 循环一次再到达 4 。

现在设想，通过 1 à 3 à 3 经过的路径也是 ab 。但此时并未到达终态。可以说，在到达 C 中的 3 时，必然选择了两个 b 以上的句子。

而这样的路径与选择句子有关系。

对于 NFA 能识别的句子，在 DFA 中也能识别。

对于 NFA 不能识别的句子，在 DFA 中也不能识别。