std::copy的限制是否比std::memcopy更宽松?

Are the restrictions of std::copy more relaxed than std::memcopy?

本文关键字：std memcopy 是否 copy 更新时间：2023-10-16

关于问题 copy vs. memcpy vs memmove

^{（顺便说一句，这里有很好的信息}），我一直在阅读，在我看来，这与口语所说的不同，例如在 cppreference 注意_{：自从引用此报价以来，memcpy 已更改为 memmove。} --

笔记
在实践中，std::copy的实现避免了多个赋值并使用大容量复制函数，例如std::memcpy如果值类型为 TriviallyCopyable

-- std::copy（也不是std::copy_backward）不能用memcopy来实现，因为对于std::copy，只有目标范围的开头不能落入源范围，但对于memcpy，整个范围不能重叠。

看看 Visual-C++ 的实现（参见 xutility 标题），我们还可以观察到 VC++ 使用 memmove，但现在它的要求比 std::copy 更宽松：

。对象可能会重叠：复制就像字符一样进行被复制到临时字符数组，然后字符是从数组中复制的...

因此，从memcpy方面实现std::copy似乎是不可能的，但使用memmove实际上是一种悲观。（有点悲观，可能无法衡量，但仍然如此）

回到问题：我的总结是否正确？这在任何地方都是问题吗？无论指定什么，是否有可能的实际实现memcpy也不能满足std::copy的要求，即当范围部分重叠时是否有memcpy实现中断std::copy允许？

如果问题是，是否有可能遇到一个高效的memcpy实现，具有足够的未定义行为，以至于在重叠范围内不信任它，那么答案是肯定的。

考虑 Power（PC）架构上 memcpy 的一种可能实现：LMW 指令将多个连续的字从内存加载到连续寄存器中（可以指定为用户定义的范围参数）。然后，STMW 会将提供的寄存器范围保存回内存。因此，我们谈论的是 CPU 在单次 memcpy 迭代期间缓冲的 ~100/200 字节（32b/64b CPU） - 如果目标范围与源范围重叠，则大量数据会破坏目标范围，特别是考虑到 CPU 不承诺单个加载和存储的相对顺序。