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

问题描述

您可以实现 Copy 特征以赋予类型copy-semantics而不是move-semantics.仅当其所有构成要素(产品类型的每个因子，或总和类型的每个变体的每个因子)也是 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.

这还允许您创建相当大的类型 Copy .如果类型的大小为大"，实施 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"?

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

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?

推荐答案

对于那些可以实现并选择退出的类型，

为什么[ Copy ]不是像 Sync 和 Send 这样的自动特征语义而不是选择加入?

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 过去通常由可以实现它的类型自动实现.此行为已在2014年12月 更改，距离Rust 1.0不久.>

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.

如果可能，是否应始终实施 Copy 特性?

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

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.

不实施 Copy 的另一个原因是，如前所述，是大类型的.对于此类类型，仅实现 Clone 可能会很有用，因为通常" Clone "而不是 Copy "表示克隆值并非便宜".".但是，即使类型不是 Copy ，也可以通过仅移动值来引起大内存复制操作(尽管如果幸运的话，编译器可能会优化它).

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).

如果类型的大小为大"，实现 Copy 会对性能产生不利影响吗?

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

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

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.

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