【问题标题】:A proposal to add statemachine support to C++-like language向类 C++ 语言添加状态机支持的提议
【发布时间】:2009-12-15 23:07:47
【问题描述】:

最近,作为我日常工作的一部分,我一直在学习 IBM Rhapsody 并使用它从 UML 生成 C++ 代码。

昨天让我感到震惊的是,考虑为我的 C++ 编译器添加状态机支持可能很酷,所以我在这里记下了一些笔记:http://ellcc.org/wiki/index.php/State_machines_and_Active_Classes

我这样做的动机是:

  1. 这似乎是一个很酷的主意。
  2. 与当前的 Rhapsody/普通 C++ 编译器相比,该编译器可以进行更好的语义检查(具有更好的错误检查)。
  3. 当编译器本身理解状态机结构时,有许多优化的可能性。

我可能会尝试将我的语法扩展到除提案之类的内容之外,看看它的效果如何。

您对该提案有何看法?它看起来可读吗?看起来值得吗?


编辑:

感谢您推荐特定库来执行状态机的答案,但这不是我的问题。我使用自己编写的库和代码实现了许多状态机。

我真的在寻找关于将状态机扩展设计为类 C++ 语言的想法、批评等,而不是这种更改是否适合添加到标准 C++ 中。将其视为特定领域的扩展,我的领域是实时控制应用程序。

我已经开始在我的编译器中实现扩展,如下所述:http://ellcc.org/wiki/index.php/State%5Fmachines%5Fand%5FActive%5FClasses

到目前为止,从提案到实施,这个概念没有太大变化,但在细节上发生了一些变化,我正在完善我对问题语义的理解。

然而,时间会证明整个概念是否有价值。 ;-)

【问题讨论】:

  • 我可能应该将这篇文章命名为“向类 C++ 语言添加状态机支持的提议”。
  • 你可以看看 Qt 状态机框架。
  • 我不太确定如何阅读。您对以下答案的一些 cmets 似乎表明您最终希望将此作为提案提交给 C++ 标准化委员会。但是在这个问题中,您说您对它是否是标准 C++ 的适当补充不感兴趣。让我有点难以弄清楚你想要什么样的反馈。
  • @jalf:我这样做是作为语言设计的实验。它可能会也可能不会有用。我正在修改我自己的编译器来实现它。从目前的反应来看,我不太可能将它作为 C++ 扩展提出。 ;-)

标签: c++ compiler-construction uml language-design state-machine


【解决方案1】:

除了少数例外,C++ 传统上使用类库而不是新关键字进行扩展。状态机可以很容易地使用这样的库来实现,所以我认为你的提议没有太大的机会。

我在您的提案中看到的一个问题是使用“goto”进入另一个状态。如果我想在状态转换中的自己的代码中使用 goto 会发生什么?

【讨论】:

  • 我知道。但是我的提议使编译器有更好的机会捕捉错误并在更高的级别上报告它们。至于我的提案的机会,这取决于我想花多少时间来实施它。
  • 标签和状态将具有单独的命名空间,因此两种形式的 goto 都可以工作。
【解决方案2】:

开发您所做的工作的出色工作。像您所做的那样可能是可能的,但我怀疑它是否会进入 C++。大多数将其纳入语言本身的更改只是为了让人们编写更有用和更强大的库。

这里有一个为状态机提供支持的库。我没有尝试过,但它可能会让您感兴趣,并且您可以将您的想法与这样的库结合起来,以便其他人使用它。

http://www.boost.org/doc/libs/1_34_1/libs/statechart/doc/index.html

或者,您可以按照自己的建议开发自己的扩展程序,它至少对您有用。 Microsoft 实现了一些扩展关键字,所以你没有理由不能创建自己的 C++ 扩展版本。

让新想法不断涌现。

【讨论】:

    【解决方案3】:

    您应该看看另一位聪明的开发人员如何将状态机支持添加到类似 C 的语言中:UnrealScript Language Reference。请参阅名为“状态”的部分。

    UnrealScript 支持状态 语言水平。在 UnrealScript 中,每个 世界上的演员总是合二为一 而且只有一种状态。它的状态反映 它想要执行的操作。为了 例如,移动画笔有几个 像“StandOpenTimed”这样的状态和 “BumpOpenTimed”。典当有几个 诸如“垂死”、“攻击”等状态, 和“流浪”。在 UnrealScript 中,您 可以编写函数和代码 存在于特定的状态。这些 函数仅在 演员处于那种状态

    【讨论】:

      【解决方案4】:

      这是一个有趣的想法,但我认为与正式扩展 C++ 相比,为状态机创建自己的领域特定语言实际上会更好。 C++ 被设计为一种非常通用的编程语言。我认为 Boost 已经证明 C++ 足够灵活,可以使用库很好地实现大多数功能。它的发展也非常缓慢,以至于到 2009 年标准 C++ 甚至还没有内置的线程支持(计划在 0x 中)。因此,委员会不太可能在一段时间内考虑添加此内容。

      【讨论】:

      • 我并不是在提议对 C++ 标准进行扩展,我只是在做一个实验。我会做自己的实现。
      • 在这种情况下,我会说去吧。您显然已经为此付出了很多思考,如果您认为为了更快、更清晰地编写基于自动机的代码而这样做是值得的,那么绝对值得一试。
      【解决方案5】:

      您的解决方案看起来与基于模板或预处理器宏的解决方案相比没有任何优势。

      我也不确定如何提供更好的语义检查。而且我怀疑您是否可以应用许多有用的代码优化。

      但是,为了实现更好的优化和语义检查,您还应该将“goto”替换为新关键字(例如__change__ newState),并禁止 goto 进行状态更改!像往常一样允许 goto 进行本地跳转。

      然后编译器可以提取可能的转换列表。

      【讨论】:

      • 感谢更改建议。无论如何,我正计划收集转换,但我认为 change 会使语言更具可读性。
      【解决方案6】:

      阅读您的建议,拥有以下 cmets:

      1. 实际上没有关键字来声明和定义实际的状态机!您是否假设一个全局状态机(因此是一个全局状态)?这与__active__ 有什么关系?

      2. C++ 中最接近的可比较结构实际上是枚举。为什么不扩展呢?

      3. 定义的事件和状态之间似乎存在某种联系,但我看不到它是如何实现的。

      4. 为什么需要线程和计时器?状态机的一些用例可能会从中受益,但一个好的建议应该将它们分开。最重要的是,这应该允许使用标准 C++0x 线程。

      就个人而言,我会扩展枚举语法:

      enum Foo {
        red, blue, green; /* Standard C++ so far - defines states. State list ends with a ; not a , */ 
        Foo() { *this = red; } // Reuse ctor syntax, instead of __initial__
        ~Foo() { } // reuse dtor syntax, instead of __onexit__
      
        void Bar() {/**/} // Defines an event, no return value. Doesn't need keyword __event__
      };
      

      很自然,您现在可以在标题中声明您的事件,并在 .cpp 文件中定义它们。我什至不需要在这里建议语法,任何 C++ 程序员都可以在这一点上猜到。为组合状态添加一点继承语法:

      enum DrawingObject : public Shape, public Color { /** } // allows (red && circle)
      

      并且您几乎已经达到了您的提案的位置,没有任何新的关键字,所有这些都是通过重用已经熟悉的语法来实现的。

      【讨论】:

      猜你喜欢
      • 2019-07-16
      • 1970-01-01
      • 2017-06-04
      • 2020-03-06
      • 2011-11-01
      • 2014-01-29
      • 2015-09-15
      • 1970-01-01
      相关资源
      最近更新 更多