使用mpl :: inherit_linearly定义接口的含义

mar*_*ark 8 c++ boost boost-mpl

我正在编写一些消息处理代码,其中每条消息都是POD结构.在写作的过程中,这将是定义一个抽象基类,每个消息类型都有虚拟函数,例如:

class AbstractHandler
{
public:
    virtual void handleMessage( const MessageType1& msg ) =0;
    virtual void handleMessage( const MessageType2& msg ) =0;
    virtual void handleMessage( const MessageType3& msg ) =0;
    virtual void handleMessage( const MessageType4& msg ) =0;
};
Run Code Online (Sandbox Code Playgroud)

然后创建实现处理函数的派生具体类:

class ConcreteHandler : public AbstractHandler
{
public:
    virtual void handleMessage( const MessageType1& msg );
    virtual void handleMessage( const MessageType2& msg );
    virtual void handleMessage( const MessageType3& msg );
    virtual void handleMessage( const MessageType4& msg );
};
Run Code Online (Sandbox Code Playgroud)

如果向系统添加新消息,则AbstractHandler必须与所有派生类型一起更新.

或者,我可以在mpl序列中保存所有支持的消息类型,并用于mpl::inherit_linearly生成抽象基类.

(注意:我已经mpl::vector在代码中的其他地方使用了一种消息类型.)

例如:

typedef mpl::vector< MessageType1, MessageType2, 
                     MessageType3, MessageType4 > message_types;

template< class Message >
class Wrapper
{
public:
   virtual void handleMessage( const Message& msg ) = 0;
protected:
   ~Wrapper(){}
};

class AbstractHandler 
     : public mpl::inherit_linearly< message_types
                                   , mpl::inherit< mpl_1, Wrapper< mpl::_2 > >
                                   >::type
{
public:
    virtual ~AbstractHandler() {}
};
Run Code Online (Sandbox Code Playgroud)

混凝土处理程序然后派生自AbstractHandler.这意味着每当向系统添加新消息类型时,只需更改mpl::vector< types... > message_types序列,添加向handleMessage派生类添加新函数即可.

在我看来,这减少了长期维护,因为AbstractHandler将自动为所有消息提供纯虚函数 mpl::vector message_types

在性能方面,使用这种方法有什么缺点吗?

使用mpl::inherit_linearly生成抽象基类有什么含义?

Kla*_*aim 3

我以前做过类似的代码(今天我又做了一次)。

除了继承引起的成本之外,没有其他成本。主要是因为最终类型是在编译时确定的,而不是运行时确定的。

但是,相对于消息类型列表的大小,这显然会使编译时间更长。如果像我一样,您也编写了一个消息调度程序类(它可以将任何内容调度到该类型的任何处理程序),那么编译时间可能会很昂贵。

否则,那很好。

只需理解这种设置的含义:处理的消息列表是在编译时而不是运行时定义的。由于使用要求,某些事件系统是运行时的。因此,请确保它是您在用例中想要的。