访谈：功能指针vs开关案例

Question

在我的访谈中，我被要求为具有100个状态的系统实现状态机，其中每个状态依次有100个事件，我回答了以下三种方法：

• if-else
• switch-case
• 函数指针

if-else显然不适合这样的状态机，因此主要的比较是在switch-case与函数指针之间，这是根据我的理解进行的比较：

• 速度方面两者几乎相同。
• Switch-case的模块化程度低于函数指针
• 函数指针有更多的内存开销。

有人可以确认上述理解是否正确吗？

Answer 1

可能存在函数指针方法的变体：包含函数指针以及其他信息的结构。所以你可以让一个函数处理几个案例。

除此之外，我认为你是对的。另外，我会考虑有关内存和速度的开销值得考虑，但希望小到可以在最后被忽略。

Answer 2

我不知道你的采访者想听到什么，我希望这不是太偏离主题但如果我正在采访某人，我会在了解你自己的合理性之前给出了解现有框架的利弊的要点，尤其是在那个规模。

C ++替代品（如果您可以使用它们，感谢glglgl指出您似乎想要C）将是：

Boost.MSM虽然在这个规模上超级快速是不可能的。原因是编译时间，mpl :: vector / list约束，因为你有一个巨大的源文件。

Boost.Statecharts可以处理100个状态，但每个状态100个事件会最大化mpl :: vector / list约束。就个人而言，如果我在一个州有100个事件，我会尝试将它们分组并使用自定义反应，但这显然取决于应用程序。

我没有看到任何理由为什么Qt的状态机不能扩展那么大（请纠正我，如果我错了）但它的数量级要慢，所以我从不使用它。

我所知道的唯一好的C选择是：

QP可以在C和C ++中使用并且可以扩展，具有良好的组织性并且“不仅仅是状态机”，因为它处理事件队列，并发和内存管理等。滚动自己可能会产生更好的性能（取决于你的技能和你投入的时间）但应该注意的是，事件的内存管理可能最终需要比状态机实现它自己更多的优化。 QP为您做到这一点非常好。

Answer 3

您可以指定有关州和事件的更多详细信息。 假设您的状态是连续整数。那你可以

1. 写一个表来包含所有状态和每个状态处理函数。 接收事件时，引用此表并调用相应的处理函数。

2. 对于每个州，编写一个包含所有事件及其事件处理函数的表。处理状态时的事件时查找此表。

查找这两个表的时间复杂度为O（1），空间复杂度为O（m * n）

但是，如何让100个状态的FSM和100种类型的事件？ 我建议你简化你的FSM设计，1~100号可能是一个特定事件的参数。