简体繁体 English

通过使用std :: copy而不是std :: memcpy复制字符时避免了libc函数调用？

[英]avoiding a libc function call when copying chars by using std::copy instead of std::memcpy?

原文 2016-09-06 08:01:37 1 3 c++/ gcc

I hope this isn't a duplicate, since similar questions have been asked. 我希望这不会重复，因为有人问过类似的问题。 I am concerned about the use of std::memcpy when gcc decides to use the libc's implementation . 当gcc决定使用libc的实现时，我担心std::memcpy使用。 This probably does not happen, if we use std::copy instead, that is, we avoid this function call into libc? 如果我们改用std::copy ，那可能不会发生，也就是说，我们避免将此函数调用到libc中？ And if so, how does the generated code compare to the libc's implementation of std::memcpy ? 如果是这样，生成的代码与libc的std::memcpy实现相比如何？

3 个解决方案

Not quite a dupe question, but here is an example of g++ calling memmove or memcpy as part of the implementation of std::copy . 这不是一个很愚蠢的问题，但这是g ++在std::copy实现中调用memmove或memcpy的示例。

In short no, using std::copy does not in general prevent GCC from using libc. 简而言之，不，使用std::copy 通常不会阻止GCC使用libc。

If you really want to block the optimization then there might be some combination of compiler options that does it, I don't know. 如果您真的想阻止优化，那么可能不知道有一些编译器选项的组合。 You'd have to look into exactly how std::copy is implemented, they might just happen to have written it in a way that it can't be disabled. 您必须仔细研究std::copy的实现方式，他们可能恰好以无法禁用它的方式编写了它。

It doesn't really matter, or help depending on your perspective. 没关系，或者根据您的观点有所帮助。

std::copy is, in at least one standard library implementation I know of, implemented in such a way that it detects if its inputs are contiguous iterators over trivially copyable types, and will just use std::memmove in that case anyway. 在我所知道的至少一个标准库实现中， std::copy实现方式是，它可以检测其输入是否为琐碎可复制类型上的连续迭代器，并且无论如何都将仅使用std::memmove 。 And the compiler may even recognize that the ranges passed are distinct and will replace that with a memcpy in turn. 而且编译器甚至可能会认识到传递的范围是不同的，并将依次用memcpy代替。

In other words, you can switch to std::copy , but chances are the compiler will just switch it back. 换句话说，您可以切换到std::copy ，但是编译器可能会将其切换回去。

std::memcpy is typically a std namespace wrapper around the C memcpy . std::memcpy通常是围绕C memcpy的std名称空间包装器。

Since most modern C libraries provide highly optimised implementations of this function, including restrict pointer arguments - a keyword not available in C++11/14 - it's probably more efficient. 由于大多数现代C库都提供了此函数的高度优化的实现，包括restrict指针参数-C ++ 11/14中不提供的关键字-可能更有效。 If the compiler can prove std::copy operates on distinct ranges, it might also use something like a __builtin_memcpy for gcc. 如果编译器可以证明std::copy在不同的范围内运行，则它还可以对gcc使用类似__builtin_memcpy的名称。 The elements would probably still be required to satisfy the is_trivially_copyable type trait, for example. 例如，可能仍然需要元素才能满足is_trivially_copyable类型特征。

The exception may be if you are using std::copy on very short ranges, and the compiler can't deduce the range length at compile time, but still generates a mem[cpy|move] call. 可能是例外，如果您在非常短的范围内使用std::copy ，并且编译器无法在编译时推断范围长度，但仍会生成mem[cpy|move]调用。 I would still be sceptical that any call overhead to a memcpy implementation would be significant. 我仍然会对memcpy实现的任何调用开销都很大表示怀疑。 You'd need to look at profiling. 您需要查看分析。