问题描述
以某种方式，VC ++(Dinkumware)上的本机stl::copy()算法指出，它可以对容易复制的数据使用memcpy().凡人可以做到这一点吗? -假设每个元素都是可以复制的.
Somehow, the native stl::copy() algorithm on VC++ (Dinkumware) figures out that it can use memcpy() on data that is trivially copy-able. Is it possible for a mere mortal to do that? - assuming each element is_trivially_copyable.
random_access_iterator是否隐含连续的内存?这个标准对我来说还不清楚.
Does random_access_iterator imply contiguous memory? The standard is not clear to me.
因此，如果模板中只有一个或两个迭代器，则是否有可能在编译时推断出可以使用memcpy()复制基础数组，如果是，该怎么做?
So, if all you have in a template is an iterator or two, is it possible to deduce at compile-time that the underlying array can be copied with memcpy(), and if so how?
编辑-这是我的动力.我有一个例程来移动数据块而不是复制它.为了在数据可记忆时加快速度，我有时将其称为stl :: copy.我想知道这是否是唯一的方法. (小时候，我总是在家中尝试.)
EDIT - Here's my motivation. I have a routine that moves a block of data rather than copying it. To get speed when the data are memmove-able, I've made it call stl::copy sometimes. I was wondering if that is the only way. (As a kid, I would always try this at home.)
// Move a range of values
template<class Ptr, class Ptr2>
inline Ptr2 move(Ptr src, Ptr end, Ptr2 dest) {
using value_type = std::iterator_traits<Ptr>::value_type;
if constexpr (std::is_trivially_copyable_v<value_type>) {
return std::copy(src, end, dest);
} else {
while (src != end) {
*dest = std::move(*src);
++src; ++dest;
}
}
return dest;
}
对于发现此相关问题的zett42表示感谢:连续迭代器检测我无法解释我怎么想念它.
Kudos to zett42 for finding this related question: Contiguous iterator detection I can't explain how I missed it.
编辑更多信息:在经历了许多曲折的小段落之后，我发现Dinkum将秘密标签用于人群中的迭代器，例如_Really_trivial_ptr_iterator_tag.所以前景看起来很暗.
EDIT More: After going down many twisty little passages all the same, I discovered that Dinkum uses secret tags for iterators that are in with the in-crowd, e.g. _Really_trivial_ptr_iterator_tag. So prospects look dim.
我的价值$ 0.02:使iterator_category成为临时类型而不是消除各种特征(例如"points_into_contiguous_memory"等)是一个初学者的错误，因为random_access_iterator是仅用标记表示的临时类型，则不能在不破坏旧版应用程序的情况下对其进行子类型化.因此，委员会现在陷入困境.我说，该重新开始了.
My $0.02 worth: It was a beginner's mistake to make iterator_category an ad-hoc type rather than busting out the various traits, like "points_into_contiguous_memory," etc... Since random_access_iterator is an ad-hoc type denoted only with a tag, it cannot be subtyped without breaking legacy applications. So the committee is now kind of stuck. Time to start over, I say.
哦，好吧.
推荐答案
A)否.它仅表示类型为F(iterator +/- n)= iterator.next/prev ..的有效映射. n存在.这根本不意味着连续分配. (范围确实适用)
A) No. It just means that a valid mapping of the kind F(iterator +/- n) = iterator.next/prev.....n exists. This does not imply contiguous allocation at all. ( bounds do apply)
B)否.这取决于实现方式.例如，如果存在2级间接访问，您可能不知道可以接收哪种数据结构.
B) No. It depends on the implementation. For instance, you might not know what kind of data structure might be received if there is a 2 level of indirection.
好消息?，您根本不需要打扰.在缓存和发生的分支预测之间，您根本不需要对其进行优化.在运行时，缓存行将充满您要复制的连续内存块，因此它将非常快，而memmove或memcpy并不会有多大帮助.
The good news?, you need not bother at all. Between the cache and the branch prediction that happens, you would not need to optimize it at all. During run time, The cache line will be filled with the block of contiguous memory you intend to copy, thus it is going to be very fast, and memmove or memcpy will not help much.
对于在运行时将指令流水线化的现代处理器，您不能保证多少，并且它们会知道该指令是否连续.
You do not guarantee much with modern processors that are going to pipeline your instructions at run time, and they would know if it is contiguous or not.
这篇关于如何从迭代器推导连续内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！