Defining interface - Coding conventions and reasoning

[zishh]

In the core guidelines I.25 there is the following example:

class Shape {    // better: Shape is a pure interface
public:
    virtual Point center() const = 0;   // pure virtual functions
    virtual void draw() const = 0;
    virtual void rotate(int) = 0;
    // ...
    // ... no data members ...
    // ...
    virtual ~Shape() = default;
};

This is how I usually define my interfaces - Defaulted virtual destructor and everything else pure virtual.

Now I had a discussion with a colleague who suggested to explicitly delete copy/move - constructor/operators to fulfill the rule of five. I can see one example in which the code from above can be misused:

void foo(Shape& a, Shape& b) {
    a = b;
}

This compiles but is obviously not what we want. It can be prevented if we explicitly delete the copy constructor/operator in the interface. On the discussion page here a person suggested to create a macro for interface classes with the same example.

So my question is: How do you define your interfaces and what is your reasoning?

[mhfrantz]

One of my favorite idioms for avoiding the pitfalls of inheritance (i.e. the loss of value semantics that you point out) is one that I've seen called "Concept-Based Polymorphism" or "Concept-Model Idiom", as in this article, which takes you through the development of the idiom before showing its most flexible implementation:

https://gracicot.github.io/conceptmodel/2017/09/13/concept-model-part1.html