有关何时在 C++ 中显式启用/禁用复制的指南课程？
一位同事正在清理几个图书馆。为此，他一直在阅读C++ 的 API 设计，其中讨论了在 C++ 类中显式启用或禁用复制。这与 Sutter 和 Alexandrescu 在他们的C++ 编码标准中所说的一样。
他同意人们应该遵循这一建议，但两本书似乎都没有说明何时启用或禁用的指导原则是什么。
有任何指导吗？谢谢！
A colleague is cleaning up a couple of libraries. In doing so he's been reading API design for C++ and it talks about explicitly enabling or disabling copying in C++ classes. This is the same thing that Sutter and Alexandrescu say in their C++ Coding Standards.
He agrees that one should follow this advice, but what neither book seems to say are what are those guiding principles that tell when to enable or disable.
Any guidance one way or the other? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这取决于类在应用程序中扮演的角色。除非
类代表一个值，其中身份并不重要，您应该
禁止复制和转让。如果类是多态的，则类似。作为一个
一般来说，如果您要分配类类型的对象
动态地，它不应该是可复制的。反之，如果该类是
可复制，您不应该动态分配它的实例。 （但
有一些例外，动态分配和分配的情况并不罕见
避免复制大对象，即使语义上另有争议。）
如果您正在设计一个低级库，那么选择就不太清楚。
像 std::vector 这样的东西可以在应用程序中扮演多种角色；在
大多数情况下，复制是不合适的，但禁止复制会
使其在少数适当的地方无法使用。
It depends on the role the classes play in the application. Unless the
class represents a value, where identity isn't significant, you should
ban copy and assignment. Similarly if the class is polymorphic. As a
generally rule, if you're allocating objects of the class type
dynamically, it shouldn't be copiable. And inversely, if the class is
copiable, you shouldn't allocate instances of it dynamically. (But
there are some exceptions, and it's not rare to allocate dynamically and
avoid copying big objects, even when the semantics argue otherwise.)
If you're designing a low-level library, the choice is less clear.
Something like
std::vectorcan play many roles in an application; inmost of them, copying wouldn't be appropriate, but banning copy would
make it unusable in the few where it is appropriate.
不可复制的类应该是例外，而不是规则。当且仅当您在复制时无法保留值语义时，您的类应该是不可复制的 - 例如，命名互斥体、唯一所有权指针。否则，你的类应该是可复制的。许多 C++ 库依赖于可复制性，尤其是 C++0x 之前的库，它们无法移动。
Classes which are non-copyable should be the exception, not the rule. Your class should be non-copyable if and only if you cannot retain value semantics while copying- for example, named mutexes, unique-ownership pointers. Else, your class should be copyable. Many C++ libraries depend on copyability, especially pre-C++0x where they cannot be movable.
与 DeadMG 相反，我相信大多数类应该是不可复制的。
Stroustrup 在他的《C++ 的设计与演化》一书中写道：
“我个人认为复制操作是默认定义的很不幸，并且我禁止复制我的许多类的对象”
Contrary to DeadMG, I believe most classes should be non-copyable.
Here is what Stroustrup wrote in his "The Design and Evolution of C++" book:
"I personally consider it unfortunate that copy operations are defined by default and I prohibit copying of objects of many of my classes"
我认为你应该尝试编写尽可能少的代码来让类做它应该做的事情。如果没有人尝试复制该类，并且在不久的将来不会复制该类，则不要添加诸如复制构造函数或赋值运算符之类的内容。只需使类不可复制即可。
当有一天您确实想要复制该类时，请添加诸如复制构造函数之类的内容。但在那之前，类不可复制意味着需要测试和维护的代码更少。
I think you should try to write as little code as possible to have the class doing what it is supposed to do. If no one is trying to copy the class and it is not going to be copied in the near future then do not add stuff like a copy constructor or assignment operator. Just make the class non copyable.
When someday you actually want to copy the class, then add things like the copy constructor. But until then having the class non copyable means less code to test and maintain.
我真诚地相信复制语义应该自动提供，或者根本不提供。
然而，写得不好的库有时可能会受益于手动复制构造函数。
请注意，C++ 中的情况与 C++0x 中的情况非常不同（因为标准库通常需要复制语义！），在 C++0x 中，我的建议几乎总是适用。
I sincerely believe that copy semantics should be provided automatically, or not at all.
However, badly written libraries may sometimes benefit from a manual copy constructor.
Note that the situation is very different in C++ (because copy semantics are usually required by the standard library !) than in C++0x, where my advice pretty much always applies.