何时明确启用/禁用C ++类中的复制的指导？

Question

一位同事正在清理几个图书馆。在这样做的过程中，他一直在阅读 C ++的API设计，它讨论了在C ++类中显式启用或禁用复制。这与Sutter和Alexandrescu在 C ++编码标准中所说的相同。

他同意应该遵循这个建议，但是这两本书似乎都没有说明什么是指示何时启用或禁用的指导原则。

任何指导方式都是这样或那样的？谢谢！

Answer 1

这取决于类在应用程序中扮演的角色。除非 class表示一个值，其中identity不重要，你应该 禁止复制和分配。同样，如果类是多态的。作为一个 一般来说，如果你要分配类类型的对象 动态地，它不应该是可复制的。反之，如果是这样的话 可复制，您不应动态分配它的实例。 （但 有一些例外，动态分配并不罕见 避免复制大对象，即使语义不是这样反对的。）

如果您正在设计一个低级库，那么选择就不太清楚了。 像std::vector之类的东西可以在应用程序中扮演很多角色;在 大多数人，复制不合适，但禁止复制会 在少数合适的地方使它无法使用。

Answer 2

不可复制的类应该是例外，而不是规则。当且仅当您在复制时不能保留值语义时，您的类应该是不可复制的 - 例如，命名的互斥锁，唯一所有权指针。否则，你的课程应该是可复制的。许多C ++库依赖于可复制性，特别是在C ++ 0x之前，它们无法移动。

Answer 3

与DeadMG相反，我相信大多数课程都应该是不可复制的。

这是Stroustrup在他的“C ++的设计和演变”一书中所写的：

“我个人认为不幸的是，默认情况下定义了复制操作，我禁止复制我的许多类的对象”

Answer 4

我认为你应该尝试尽可能少地编写代码来让类完成它应该做的事情。如果没有人试图复制该类并且不会在不久的将来复制它，那么不要添加像复制构造函数或赋值运算符这样的东西。只是让课程不可复制。

有一天你真的想复制这个类，然后添加像复制构造函数这样的东西。但在此之前，让类不可复制意味着需要更少的代码来测试和维护。

Answer 5

我真诚地相信应该自动提供复制语义，或者根本不提供复制语义。

但是，编写糟糕的库有时可能会受益于手动复制构造函数。

请注意，C ++中的情况非常不同（因为标准库通常需要复制语义），而不是C ++ 0x，我的建议几乎总是适用。