通过 switch 和 static_cast 访问多态对象的运行时类型

Posted 2023-02-23

【中文标题】通过 switch 和 static_cast 访问多态对象的运行时类型

【英文标题】：Accessing the runtime type of a polymorphic object by switch and static_cast

【发布时间】：2018-10-27 12:33:07

【问题描述】：

我想使用异步事件模式来解耦我的程序。我还想让基事件类忽略实现，以便在事件中传递我喜欢的任何内容。因此，在我看来，在开关内使用 static_cast 似乎是一个简单且可能安全的解决方案：

enum class EventType

    None,
    EventA,
    EventB
;

class BaseEvent

    public:
        BaseEvent(EventType t = EventType::None) : type(t)  
        virtual ~BaseEvent() 
        auto get_type()  return type; 
    private:
        EventType type;

    // Oblivious and clean interface
;

class EventA : public BaseEvent

    public:
        EventA() : BaseEvent(EventType::EventA)  

    // ... whatever I like
;
class EventB : public BaseEvent

    public:
        EventB() : BaseEvent(EventType::EventB)  

    // ... whatever I like
;

void handle_event(BaseEvent* pe)

    switch (pe->get_type())
    
        case EventType::EventA:
        
            EventA* original_a = static_cast<EventA*>(pe);

            // In this case I know what is "pe" and what 
            // operations and data I can access and use.

            break;
        
        case EventType::EventB:
        
            EventB* original_b = static_cast<EventB*>(pe);

            //...

            break;
        
    

但我也知道使用 static_cast 会带来一些风险，因为它会破坏类型检查。从我理想主义的角度来看，在这种情况下似乎并不那么危险，即使对于未来的可维护性也是如此。必须只检查该行

case EventType::EventA:

与下面一行一致

EventA* original_a = static_cast<EventA*>(pe);

我知道从理论上讲，这似乎不是一个问题，但实践确实不同。该解决方案是否适用于大型项目？有没有更好的策略来实现这种模式？

我知道我可以在基类中使用 std::variant 的数组或向量，但它似乎对派生事件的可能实现非常有限。我也可以使用映射来存储参数名称和它们的值，但它似乎很慢，内存不友好，并且同样限制了可能的参数类型。

或者，我也可以使用dynamic_cast，虽然有它的开销，但也许它可以偿还增加可维护性的成本。

编辑

为了简洁起见，我忘记提及有关该问题的一些重要细节：

事件必须以多态方式在容器中排队，所以我认为 CRTP 是不可行的。

上下文是基于代理的实时模拟（视频游戏），其中我有一个主循环遍历事件。这些事件可以在每次迭代的任何地方触发。它们将在以下迭代中由特定处理程序处理。

std::queue<BaseEvent*> past_events;

int main()

    while (true)
    
        while (!past_events.empty())
        
            handle_event(past_events.front());

            //handle_event2(...)
            //handle_event3(...)
            //...

            past_events.pop();
        

        // New events are fired...
    

【问题讨论】：

如果你想要静态多态，看看CRTP。

另请注意，此类结构通常是设计缺陷的明显标志。

这是一种被广泛接受的做法（甚至回到 C 代码中）。它甚至有一些库例程。见LLVM-style RTTI。

@πάνταῥεῖ 感谢您的建议。我添加了有关上下文的更多详细信息。我认为使用 CRTP 派生的 BaseEvent 无法存储在容器中。对吗？

@VTT 谢谢我现在才阅读这篇文章。这让我对这种模式更有信心

【参考方案1】：

分析您的设计

乍一看，可能会认为这是次优设计，因为您不使用多态性让事件自己执行正确的操作，而不是让事件处理程序切换和强制转换。但是当阅读你的论点时，会出现另一幅画面：

您决定故意将处理事件的逻辑放在事件处理程序中。这允许您将事件处理与事件本身分离。换句话说，不同的事件处理程序可能对同一事件有完全不同的行为（取决于上下文、事件接收器、应用程序等），就像每个 Windows 应用程序都有一些事件循环并对相同的事件做出反应一样一种完全不同的方式。

所以你故意选择不把行为放在事件中，因此你不能在事件中使用多态性。不了解上下文，很难建议另一种方法。

后果

由于您已经在基类中定义了获取事件类型的逻辑，因此您可以假设您非常了解它的类型并选择static_cast。但是……

风险编号 1

然而，存在一种严重的风险，即有一天使用错误的事件类型（复制和粘贴、拼写错误等）创建了一种新的事件类型。这可能会导致 UB。

风险缓解：

使用dynamic_cast 在运行时拦截每个事件处理程序中的此类不一致。请注意，维护人员可能会忘记这一点，因此这是降低风险而不是预防风险 或预见一个测试套件，它创建所有事件类型并在构建时执行dynamic_cast 一致性检查。

风险编号 2

您可能有一些意外的事件副本（复制构造函数或赋值），无论是否有切片，都会意外覆盖事件的真实类型（例如if (*eventA=*eventB) /* ouch!! == */）。

风险缓解：从事件基类中删除复制构造函数和赋值，以防止此类事故。

【讨论】：

感谢您的分析。我已经编辑了问题，添加了有关上下文的更多详细信息。您认为这仍然是一种可行的模式（您强调的风险的一部分）？

@Tarquiscani 我看到在你的主循环中有几个事件处理程序，这可以证明你的设计是合理的。多重分派（即多态性取决于事件处理程序和事件）将需要处理程序和事件之间的耦合，并且在添加新事件类型时具有类似的缺点。其他替代方案（例如表驱动调度）不会更容易维护错误。所以是的，我认为我的分析仍然有效。是的，我强烈推荐建议的缓解措施。