状态机类不应继承基类,而应采用std::function+值语义封装,用stateid(statedata&, const event&)签名统一处理状态迁移,避免虚函数开销、生命周期风险与跨线程脆弱性。

状态机类要不要继承基类?
C++里写FSM,很多人第一反应是搞个抽象基类 State,再让具体状态去继承。这看似“面向对象”,但实际容易卡在虚函数调用开销、对象生命周期管理、状态切换时的析构/构造抖动上。更关键的是:一旦状态逻辑要跨线程或需序列化,继承体系会迅速变脆。
建议直接放弃继承基类模式,改用 std::function + 值语义封装。每个状态就是一个可调用对象(比如 lambda 或普通函数),状态迁移通过返回下一个状态的值来表达,不依赖 this 指针或虚表。
- 状态数据全部存于 FSM 实例内(如
struct StateData),由用户控制生命周期 - 状态函数签名统一为
StateId(StateData&, const Event&),避免隐式转换和重载歧义 - 不允许状态函数内部 new/delete 临时状态对象,防止悬挂指针
怎么避免状态跳转时的重复判断?
常见错误是把所有转移逻辑塞进一个大 switch 或 if-else 链,每次事件进来都从头比对。这不仅难维护,还会因分支预测失败拖慢热点路径。
正确做法是预建一张二维跳转表:用 std::array<:array num_events>, NUM_STATES></:array>,索引为当前状态和事件类型。初始化阶段填好,运行时 O(1) 查表。
- 表格大小必须编译期确定,推荐用
enum class StateId : uint8_t和enum class Event : uint8_t,确保数值连续且范围可控 - 未定义转移填
StateId::INVALID,并在运行时 assert 检查,而不是静默忽略 - 若事件类型过多(>64),改用
std::unordered_map<event stateid></event>,但需接受哈希开销和内存碎片
事件如何设计才能不污染状态逻辑?
把事件定义成裸 struct(如 struct TimerExpired { int timer_id; };)比用整型码+全局 switch 更安全。但问题在于:FSM 类不能为每种事件类型硬编码处理分支,否则新增事件就得改 FSM 主体。
组合式C++代码评审方案,融合静态分析、AI推理、多轮迭代评审和C++专项检查,适用于PR审查、增量代码审查、全项目评审和代码质量评分,触发词包括review cpp、cpp代码评审、C++review、代码审查。
解法是用访客模式轻量版——让事件自己携带处理逻辑:
struct Event {
virtual StateId handle(StateData& data) const = 0;
};
struct ButtonPressed : Event {
StateId handle(StateData& d) const override {
d.last_press_time = now();
return d.mode == Mode::IDLE ? StateId::ACTIVE : StateId::ALERT;
}
};
- 所有事件类型必须 final,禁止多层继承,避免虚函数调用链过长
-
handle()函数只读写StateData,不访问 FSM 外部资源(如 IO、全局单例) - 如果事件来自外部系统(如网络包),应在进入 FSM 前完成反序列化并转成对应
ButtonPressed等具体类型,别传 raw buffer 进去
为什么 move-only 的 FSM 实例反而更安全?
允许拷贝 StateMachine 对象看似方便,但极易引发状态不一致:比如两个副本各自处理不同事件,或一个副本销毁后另一个还在调用已释放的 StateData。
强制 move-only(删掉拷贝构造/赋值,保留移动)能从编译期堵住这类错误:
class StateMachine {
StateMachine(const StateMachine&) = delete;
StateMachine& operator=(const StateMachine&) = delete;
public:
StateMachine(StateMachine&&) = default;
StateMachine& operator=(StateMachine&&) = default;
};
- 移动后原实例变为 valid-but-unspecified 状态,
assert(!sm.is_running())可加在移动后检查 - 所有状态函数接收
StateData&而非StateData*,彻底规避空指针风险 - 如果需要共享状态(如日志句柄),用
std::shared_ptr包裹资源,而非让 FSM 自己持有原始指针
状态解耦的难点不在结构设计,而在约束边界——比如谁负责清理定时器、谁触发外部回调、事件是否可重入。这些必须在定义 StateData 成员时就明确所有权,而不是等跑出 core dump 才回头补 lock。
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!










