C++ – Member and Function Injection Across Multiple Classes

aspect-orientedcc++11

I have a problem in which a variety of classes in C++ will want some functionality that is neither a "has a" nor an "is a" relationship.
The problem is that there are some members with associated functions having to do with handling player pointers that some menus and in game objects will need to have.
I could copy the functionality across all of them, but I'd rather inject the functionality as advice, so that the functionality is shared.
The classes that need the functionality do not share a super in the class tree.

Normally I might use something akin to aspect orientation, making an Aspect that has all the desired functionality and adding it to all of the classes as advice, but because of the C++ codebase at the company I cannot do this.

Is there a good "plain C++" solution to this that I'm overlooking? (c++11 allowed)
Right now I hope to use interfaces to do something similar.

edit:
i'll be experimenting with each solution, perhaps asking further questions, and will figure out the best solution within the next few days.
want to give this thorough consideration for future use.

Best Answer

Is all the functionality known at compile time? If so, template metaprogramming might work. See a real example here, but something like this ---

template<class T> ExtraFunctionality {
  //do something with instances of class T
}

template<class T> OtherExtraFunctionality {
  //do something else with instances of class T
}

template< template<class> class Extras = ExtraFunctionality >
class Menu: public AbstractMenu, Extras<Menu> {
  typedef Extras<Menu> Ext;  //for convenience - not required
  //do something with what you inherited from Extras.
}

template< template<class> class Extras = ExtraFunctionality >
class GameObject: public AbstractGameObject, Extras<GameObject> {
  //same deal
}

now you can instantiate

Menu<> menu;

for the Menu with ExtraFunctionality or

Menu<OtherExtraFunctionality>

if you want something different.

This is an example of CRTP mentioned by @Deduplicator.

Related Solutions

C++ – Writing cross-platforms Types, Interfaces and Classes/Methods in C++

The easiest way to think about cross-platform programming is that you need a strategy for dealing with changes in the behaviour of the program's environment, across space (i.e. different hardware architectures and operating systems) and time (i.e. different versions of an operating system with new features and different bugs). There already is a pattern for implementing strategies.

You can imagine defining a polymorphic type with member functions that define the "logic" of what you're trying to do. These member functions call abstract member functions that are responsible for entertaining the underlying platform's needs. Clients call a factory method to get an instance of your class: the factory method chooses what concrete implementation to return based on the details of the platform.

This approach results in a public interface with no templates and (with the information I know about the problem) no explicit pointer use. Clients just call a factory method and then use the public interface on your virtual base class. It also completely hides all of the complexity you want to introduce regarding headers and their locations - your clients just include the headers for your virtual types.

C++ – the pattern for a safe interface in C++

The canonical way to create an interface in C++ is to give it a pure virtual destructor. This ensures that

No instances of the interface class itself can be created, because C++ does not allow you to create an instance of an abstract class. This takes care of the not constructible requirements (both default and copy).
Calling delete on a pointer to the interface does the right thing: it calls the destructor of the most-derived class for that instance.

just having a pure virtual destructor doesn't prevent assignment on a reference to the interface. If you need that to fail as well, then you must add a protected assignment operator to your interface.

Any C++ compiler should be able to handle a class/interface like this (all in one header file):

class MyInterface {
public:
  virtual ~MyInterface() = 0;
protected:
  MyInterface& operator=(const MyInterface&) { return *this; } // or = default for C++14
};

inline MyInterface::~MyInterface() {}

If you do have a compiler that chokes on this (which means it must be pre-C++98), then your option 2 (having protected constructors) is a good second-best.

Using boost::noncopyable is not advisable for this task, because it sends the message that all classes in the hierarchy should be non-copyable and it can thus create confusion for more experienced developers who wouldn't be familiar with your intentions for using it like this.

Best Answer

Related Solutions

C++ – Writing cross-platforms Types, Interfaces and Classes/Methods in C++

C++ – the pattern for a safe interface in C++

Related Topic