实施“层级状态机” （HSM）在现代C＆＃x2B;＆＃x2B;中

Question

在过去的几天里，我一直在玩这个，但不确定最好的设计方法是什么 - 尤其是在顶级界面方面。我已经看过了：

https://barrgroup.com /嵌入式系统/操作/简介/介绍 - 结构 - 状态

和这篇相当古老的文章确实：

https://state-machine.com/doc/heinzmann04.pdf

，想知道如今使用现代C ++可以做些什么及其提供的功能，包括高级元编程设施，例如Boost In Boost。

对于那些不知道的人来说，“层次状态机”基本上是对“有限状态机”的重组因此，从技术上讲，每个内部“ FSM”的水平都不在过渡下关闭，因此不是真正的FSM），从而使一个更大的表现力能够建模有条件关系的关系，这些关系经常在GUIS之类的东西中出现，其中一组小部件的状态可能会影响另一个可能影响三分之一的集合，同时也改善代码重复使用。当我注意到我的旧GUI代码多么混乱，然后找到了这种模式时，我想到了一个镜头。

特别是，我的HSM的“理想”接口看起来像这样：

class MyHsm : public Hsm<MyHsm, int> {
    public:
        MyHsm() : m_data(0) {}
    private:
        int m_data;
};

class MyHsmRootState : public HsmRootState<MyHsm> {
    public:
        void enter(MyHsm *a_hsm) const { ... }
        void exit(MyHsm *a_hsm) const { ... }
};

class MyHsmState1 : public HsmInnerState<MyHsmRootState> {
    public:
        void enter(MyHsm *a_hsm) const { ... }
        void exit(MyHsm *a_hsm) const { ... }
};

class MyHsmState2 : public HsmDefaultInnerState<MyHsmRootState> {
    public:
        void enter(MyHsm *a_hsm) const { ... }
        void exit(MyHsm *a_hsm) const { ... }
};

class MyHsmState11 : public HsmValidState<MyHsmState1> {
    public:
        void processInput(int a_input) const { ... }

        void enter(MyHsm *a_hsm) const { ... }
        void exit(MyHsm *a_hsm) const { ... }
};

class MyHsmState12 : public HsmDefaultValidState<MyHsmState1> {
    public:
        void processInput(int a_input) const { ... }

        void enter(MyHsm *a_hsm) const { ... }
        void exit(MyHsm *a_hsm) const { ... }
};

class MyHsmState21 : public HsmValidState<MyHsmState2> {
    public:
        void processInput(int a_input) const { ... }

        void enter(MyHsm *a_hsm) const { ... }
        void exit(MyHsm *a_hsm) const { ... }
};

class MyHsmState22 : public HsmDefaultValidState<MyHsmState2> {
    public:
        void processInput(int a_input) const {
            if(a_input == 0) {
                hsmTran<MyHsmState21>(a_hsm); // or whatever
            }
        }

        void enter(MyHsm *a_hsm) const { ... }
        void exit(MyHsm *a_hsm) const { ... }
};

使用继承树来表示状态层次结构，并且要启动HSM，我们做的

void f() {
    MyHsm hsm;
    hsm.commence<MyHsmRootState>();
    ...
}

想法是，在调用此命令后，HSM必须过渡到最内向的默认状态（仅HSM实际上是在叶子中，即没有进一步遗传的状态，这也意味着在所有状态也在所有状态中也进一步延续了层次结构）。这是myhsmstate22。这就是我发现实施棘手的行为。

特别是，为了进行这种过渡，myhsm以某种方式必须知道， derived class myhsmstate2继承了HSMDEFAULTINNENNERSTATE＆lt; myhsmrootstate＆gt;来自myhsmrootstate（它知道），然后继续知道，从中， ，派生的类myhsmstate22代码>。问题是，有什么办法可以做到吗？我想出的任何内容似乎都至少非常复杂（即使不是外部代码处理器来扫描C ++代码并生成某种注释a la qt的MOC）。

我想到的替代方案是更改接口以安抚实现的约束，而是将默认设备视为类型成员，因此在Templatese中很容易访问向下点的链接：

class MyHsmRootState : public HsmRootState<MyHsm> {
    public:
        typedef class MyHsmState2 Default;

        void enter(MyHsm *a_hsm) const { ... }
        void exit(MyHsm *a_hsm) const { ... }
};

但是，这需要向前声明，因此实际上是有效的myhsmrootstate的周期性依赖性在myhsmstate2上，相反。也就是说，如果它简化了事情并使代码更加整洁，那就不会受伤，对吗？但是我还听说，通常引入周期性依赖性不是“好实践”。