我希望这不是重复的,因为有人问过类似的问题。当gcc决定使用libc的实现时,我担心std::memcpy
的使用。如果我们使用std::copy
,也就是说,我们避免了对libc的此函数调用,那么这种情况可能不会发生?如果是,生成的代码与libc的std::memcpy
实现相比如何?
这不是一个容易理解的问题,但这里有一个g++调用memmove
或memcpy
作为std::copy
实现的一部分的示例。
简而言之,不,使用std::copy
通常不会阻止GCC使用libc。
如果你真的想阻止优化,那么可能有一些编译器选项的组合可以实现,我不知道。你必须仔细研究std::copy
是如何实现的,他们可能只是碰巧以一种不能禁用的方式编写了它。
这并不重要,也不重要,取决于您的观点。
在我所知的至少一个标准库实现中,std::copy
的实现方式是检测其输入是否是可复制类型上的连续迭代器,并且在这种情况下无论如何都只使用std::memmove
。编译器甚至可以识别出传递的范围是不同的,并将依次用memcpy
替换它。
换句话说,您可以切换到std::copy
,但编译器很可能只是将其切换回来。
std::memcpy
通常是围绕C memcpy
的std
命名空间包装器。
由于大多数现代C库都提供了该函数的高度优化的实现,包括restrict
指针参数(一个在C++11/14中不可用的关键字(,因此它可能更高效。如果编译器能够证明std::copy
在不同的范围上运行,那么它也可能对gcc使用类似__builtin_memcpy
的东西。例如,可能仍然需要这些元素来满足is_trivially_copyable
类型的特征。
如果在非常短的范围内使用std::copy
,并且编译器在编译时无法推断范围长度,但仍会生成mem[cpy|move]
调用,则可能会出现异常。我仍然怀疑memcpy
实现的任何调用开销是否会很大。您需要查看配置文件。