C ++不可复制类和多重继承，纯抽象类

Question

We can probably agree that default copy construction is bad most of the time in C++, so it's better to disable it explicitly with either C++11 =delete or non-copyable classes like boost::noncopyable .

The question is, what happens in advanced scenarios when we use multiple inheritance or public abstract classes?

//Class uncopyable
class uncopyable {...};

//Interface1
class IInterface1 : private uncopyable
{
public:
 IInterface1(...)
 virtual ~IInterface1(...) = 0;
};

//Interface2
class IInterface2 : private uncopyable
{
public:
 IInterface2(...)
 virtual ~IInterface2(...) = 0;
};

//Fancy implementation
//FImpl
class FImpl : public IInterface1, public IInterface2, private : uncopyable
{
public:
 FImpl(...) {...}
 ~FImpl(...) {...};
};

• Is it a good practice to make every interface non-copyable (it seems it is, to avoid slicing)?
• Is it a good practice to add non-copyable to every derived class (explicit safeguard, but causes multiple inheritance and diamond problems?)

Answer 1

No, it's not a good idea to make interface non-copyable. For example, that prevents cloning.

And no, it's not a good idea to derive from non-copyable in every derived class, because it's just redundant.

However, in order to stop especially Visual C++ from spewing out silly-warnings, it can be a good idea to declare a copy constructor and copy assignment operator in every class that should be non-copyable.

Answer 2

A pure virtual (interface) class has no need to enforce the memory management for the use of the interface. Implementations of pure virtual interfaces should determine their own memory management requirements (like copy and assign).

That said, value semantics allow implementations to avoid this situation entirely. A value class (copyable, assignable, etc.) is easier to reason about and use. All of the classes in the C++ library are value classes. A good example of a value class managing memory for itself is the venerable string class. Vector is also a good example. These classes have complex internal memory management requirements, yet, as a user of these classes, I don't have to be concerned with that aspect of the class. I can focus on how to use the class.

I like this presentation from C++ Now that shows how polymorphism is also an implementation detail. This includes the ability for a client to implement classes that can participate in the polymorphism without requiring an interface class (or any base class for that matter).