Question

Suppose I have an abstract base class, that just defines a container on which addition can be performed:

class Base {
public:
    virtual ~Base() {}
    virtual Base operator+(const Base& rhs) =0;
};

Then I want subclasses of Base to provide the actual operation:

class Derived: public Base {
public:
    Base operator+(const Base& rhs) { // won't compile
        // actual implementation
    }
};

Here is my problem: operator+() is supposed to return a new Base object, but Base being abstract it won’t compile.

I tried to get around that by using a factory to return a reference to a Base object, but then in the body of the operator I find myself doing casts, because the addition only makes sense on Derived objects.

In any case, it feels like I am biting my own tail, is there a proper solution to this?

UPDATE: Based on the answers so far, it seems I am using the wrong pattern. I want to separate the interface from the implementation, so that library code only has to know the interface and client code provides the implementation. I tried to do that by providing the interface as an abstract base class, and the implementation as subclasses.

UPDATE2: My question was actually 2 questions, a concrete one (about overloading operators in abstract classes) and another about my intent (how do I allow the client to customize the implementation). The former has been answered: don’t. For the latter, it seems that the Interface Class pattern I use is actually a good one to solve that problem (according to Griffiths and Radford), it’s just that I should not mess with overloaded operators.

Answer 1

The best thing is not to.

operator+ returns a value and you can’t return a value of an abstract type, by definition. Overload the operators only for concrete types and avoid inheriting from concrete types to prevent “slicing by overloaded operator”.

Overload symmetric binary operators like operator+ as free functions and you can control which combinations of types can be sensibly combined, and conversely prevent the combination of objects of types for which the combination doesn’t make sense.

If you have a valid way of performing an “add” via two base class references and creating a new object you will have to return via a pointer, reference or pointer-wrapping smart object. Because you can’t preserve the conventional semantics of + I would recommend using a named function, e.g. Add() instead of making an operator+ with a “surprising” syntax.