如果可能，是否应该始终实现 Copy 特征? [英] Should the Copy trait always be implemented if possible?

问题描述

您可以实现 Copy 特征以提供类型复制语义而不是移动语义.只有当它的所有组成元素(产品类型的每个因素，或 sum 类型的每个变体的每个因素)也是 Copy 时，才能做到这一点.

这也允许你制作相当大的类型Copy.如果类型的大小为大"，那么实现 Copy 是否会损害性能?

如果应该始终实现 Copy，为什么对于那些可以实现它的类型，它不是像 Sync 和 Send 这样的自动特征并具有选择退出语义而不是选择加入?

解决方案

为什么 [Copy] 不是像 Sync 和 Send 这样的自动特征，用于那些可以实现它并可以选择退出的类型语义而不是选择加入?

Copy 曾经由可以实现它的类型自动实现.在 2014 年 12 月 改变了这种行为，在 Rust 1.0 之前不久.p><块引用>

如果可能，是否应该始终实现 Copy 特征?

不一定.在开发库时，选择是否在类型上实现 Copy 会影响前向兼容性.删除类型上的 Copy 实现是一项重大更改(该类型的用户可能依赖于被复制而不是移动的类型)，因此会对库施加主要版本的影响，以便尊重语义版本控制.特别是，如果一个类型现在能够实现 Copy，但您认为该类型可能会演变为不再实现 Copy，那么您应该谨慎行事而不是在该类型上实现 Copy.

不实现 Copy 的另一个原因是，正如您所提到的，大型类型.对此类类型仅实现 Clone 可能很有用，因为通常Clone 但不是 Copy"表示克隆值并不便宜"".然而，即使一个类型不是Copy，仍然可以通过仅仅移动值来导致大的内存复制操作(虽然如果你幸运的话，编译器可能会优化它).

<块引用>

如果类型的大小为大"，那么实现 Copy 是否会损害性能?

如果您从不对该类型执行复制，则不会！请记住，move 和 copy 之间的唯一区别是移动会使源无法使用(即，如果您尝试使用某个值，编译器将引发错误移动后)，而副本没有；这两个操作都是作为浅层内存副本实现的.

You can implement the Copy trait to give the type copy-semantics instead of move-semantics. This can only be done if all its constituent elements (each factor of a product type, or each factor of each variant of a sum-type) are also Copy.

This allows you to also make rather large types Copy. Can implementing Copy be detrimental to performance if the size of the type is "large"?

If Copy should always be implemented, why is it not an auto-trait like Sync and Send for those types which can implement it and have opt-out semantics instead of opt-in?

解决方案

why is [Copy] not an auto-trait like Sync and Send for those types which can implement it and have opt-out semantics instead of opt-in?

Copy used to be automatically implemented by types that could implement it. This behavior was changed in December 2014, not too long before Rust 1.0.

Should the Copy trait always be implemented if possible?

Not necessarily. When developing a library, the choice to implement Copy or not on a type has an impact on forward compatibility. Removing a Copy implementation on a type is a breaking change (users of that type may rely on the type being copied instead of moved), and as such would impose a major version bump on the library in order to respect semantic versioning. In particular, if a type is able to implement Copy now but you think it's possible that the type may evolve such that it could no longer implement Copy, you should play it safe and not implement Copy on that type.

Another reason for not implementing Copy is, as you mentioned, large types. It may be useful to implement only Clone for such types, as usually "Clone but not Copy" indicates that cloning the value is not "cheap". However, even if a type is not Copy, one could still cause a large memory copy operation by merely moving the value (though if you're lucky, the compiler might optimize it away).

Can implementing Copy be detrimental to performance if the size of the type is "large"?

Not if you never perform a copy on the type! Keep in mind that the only difference between a move and a copy is that a move makes the source unusable (i.e. the compiler will raise an error if you try to use a value after it was moved), while a copy doesn't; both operations are implemented as a shallow memory copy.

这篇关于如果可能，是否应该始终实现 Copy 特征?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！