为什么没有std :: move_n算法? [英] Why is there no std::move_n algorithm?

问题描述

我假设有一个 std :: copy_n ，以便它可以与输入迭代器一起使用.出于相同的原因，为什么没有 std :: move_n 会出于某些原因?

I'm assuming that there is a std::copy_n so that this can work with input iterators. Is there some reason why there is no std::move_n for the same reason?

推荐答案

我认为答案可能很平凡.

I think the answer is probably pretty mundane.

std :: copy 一直存在，它是C ++ 03中这些算法中唯一的一种.

std::copy existed forever, it was the only one of these algorithms in C++03.

N1377 (2002)在语言中添加了移动语义，还引入了 std :: move()和 std :: move_backward()算法以镜像现有的 std :: copy()和 std :: copy_backward().这些是现有的唯一复制算法-因此，它们是唯一具有 move 版本的算法.

N1377 (2002) added move semantics into the language and also introduced the algorithms std::move() and std::move_backward() to mirror the existing std::copy() and std::copy_backward(). Those were the only copying algorithms in existence - so those were the only ones that got move versions.

N2569 (2008)添加了更多算法，大多数算法都存在于原始标准模板库实现中-这是 std :: copy_n()和 std :: copy_if()的来源.由于本文的前提是一堆已经存在并使用多年的算法，因此不可能包含 std :: move_n()或

N2569 (2008) added a bunch more algorithms, most of which existed in the original Standard Template Library implementation - this is where std::copy_n() and std::copy_if() came from. Since the premise of the paper was a bunch of algorithms that have been around and used for years, it couldn't have included std::move_n() or std::move_if(). It seems that this simply wasn't considered.

我猜这些是否以相反的顺序发生，我们今天可能有 std :: move_n().但是在这一点上，可能不值得添加.因为 std :: copy_n()甚至都不经常使用，并且 move_n 却很容易实现:

I'm guessing if these happened in the opposite order, we might have had std::move_n() today. But at this point, it might not be worth adding. Since, std::copy_n() isn't even used super often and move_n is very easy to implement:

template< class InputIt, class Size, class OutputIt>
OutputIt move_n(InputIt first, Size count, OutputIt result)
{
    return std::copy_n(std::make_move_iterator(first), count, result);
}

这篇关于为什么没有std :: move_n算法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！