我已经使用 FSM/Pushdown Automaton 方法构建了一个解析器，就像这里（它工作得很好！）：C++ FSM 设计和所有权 当解析器出现问题时，它允许我优雅地退出并向用户输出有用的错误消息阶段。
我一直想知道在我的程序的其余部分中完成这项工作的好方法，自然而然地，解析器方法突然出现在我的脑海中......
我会让每个对象成为一个状态，它有一个 event() 函数，该函数有一个 switch 语句，根据我所处的执行阶段调用对象特定的函数。我可以使用特定于对象的枚举来跟踪它，并使代码更具可读性（case parser比 更具可读性case 5）。这将允许我关闭我创建的状态的下推树（使用m_parent*我的另一个问题中的方法）。
这是一个好的设计（强制所有东西都处于 FSM 模式）吗？有没有更好的方法，它会复杂多少（我发现 FSM 很容易实现和测试）？
感谢您的建议！
PS：我知道 boost 拥有人们可能需要的一切，但我想限制外部依赖，尤其是在 boost 上。c++0x 虽然没问题（但我认为在这里并不重要）
你所做的有点像在你的程序中构建一个（简单的）虚拟机。FSM 往往非常适合一些受限问题，例如词法分析和解析，并且您可能已经注意到，您可以“免费”获得相当多的日志记录和错误管理。
但是，如果您尝试将 FSM 模式应用于所有事物（这对于例如包含很多您通常不希望进入显式状态的状态的 GUI 程序来说将是困难的），您将意识到您还需要调试FSM 的工具（因为 C++ 调试器不会理解您的状态和事件）以及链接和重用状态的工具（因为状态不会是 OO 级别的构造）。如果您想将代码交给其他人，他或她将需要额外的培训才能成功使用您的 FSM。您是否要为多个应用程序保留一个 FSM 引擎？如果是这样，您将如何处理版本控制和升级？
为正确的工作使用正确的工具。每种方法都有其优点和缺点。您的解决方案增加了另一层复杂性：您可以以更多 C++ 方式处理日志记录和错误处理。如果您对编写 C++ 代码不满意，您可能会考虑使用其他现有语言，而不是构建只有您理解的 FSM 语言。
您可以随时查看boost。
大多数人会使用继承而不是 switch/case/default。然而，强迫一切都是一种方式的想法本质上是错误的。您应该始终根据其自身的优点来处理每个必需的功能。