Consequences of using mpl :: inherit_linearly to define interfaces

Question

I am writing message processing code in which each message is a POD structure. In the writing method, this will define an abstract base class with virtual functionality for each type of message, for example:

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; }; 

And then create derived concrete classes that implement the functions of the handler:

 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 ); }; 

If new messages are added to the system, AbstractHandler must be updated along with all derived types.

Alternatively, I could support all supported message types in the mpl sequence and use mpl::inherit_linearly to generate an abstract base class.

(Note: I already use mpl::vector message types elsewhere in the code.)

eg:

 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() {} }; 

Concrete handlers are then derived from AbstractHandler . This means that whenever new types of messages are added to the system, this is just a case of changing the sequence mpl::vector< types... > message_types , adding new handleMessage functions to derived classes.

In my opinion, this reduces long-term maintenance, since AbstractHandler will automatically have pure virtual functions for all messages in mpl::vector message_types

Regarding performance, are there any flaws in using this approach?

What are the implications of using mpl::inherit_linearly to generate abstract base classes?

Answer 1

I have done similar code before (and I am doing it again today).

There is no cost other than the cost of inheritance. Mostly because the final type is determined at compile time, and not at run time.

However, this can obviously make your compilation time longer than the size of the list of message types. If you, like me, you also write a message manager class (which can take anything to send some kind of handler for this type), then this can be expensive at compile time.

Otherwise, it’s good.

Just familiarize yourself with the implication of this type of configuration: the list of processed messages is determined at compile time, and not at run time. Due to usage requirements, some event systems are executable. Therefore, make sure that you want in your use cases.