Question

可能重复：
STL algorithms taking the whole container rather than .begin(), end() as arg?

我一直在研究一些算法，我想知道为什么它们中的一些还没有容器中的变体。

例如，find可以接受容器和值，算法可以通过调用容器的begin和end在容器内部迭代。与unique_copy相同，对我来说传递容器更有用，算法使用push_back而不是需要迭代器，我将被迫将数组的大小调整为最大元素数。 for_each是另一个这样的例子。

我确信有充分的理由我不知道？

Answer 1

我可以看到两个主要原因：

为容器添加重载会使函数数量增加一倍以上：对于每个只占一个范围的算法，重载会加倍。但是，对于像std::copy()这样的东西，你有两个范围，每个范围都要独立地指定为范围（正确的抽象不是容器，BTW，而是游侠）或一对迭代器，使它成为已经有4次重载。
一旦范围进入图片，就不能完全清楚需要返回的内容。您的示例使用std::find()，当它将迭代器作为参数时，它会清楚地返回迭代器。当给定范围时，返回另一个范围实际上可能更合理。更糟糕的是，除非你最初有一个通过范围（例如，从流中读取的东西），否则甚至可以选择两个不同的范围，即开始找到对象，并找到要结束的对象。另一个维度可以是获取所选范围的副本而不是迭代器分隔的范围。

当最初提出STL时，它首先被认为是Crazy Talk！试图说服人们打开另一种主要的蠕虫来正确处理范围可能很容易扼杀整个想法。然后立即采取后续问题：为什么这不会改变？ ......这个问题也有两个答案：

我没有提出改变的界面，尽管当我将其提交给图书馆工作组时，草案版本被认为是合理的。然而，我概述的提案没有得到很大的热情。此外，当时我不知道如何实际实现我设想的可接受的努力的界面（使用C ++ 2011功能，我知道如何做到这一点）。我已经开始写description of a new interface of STL了，但即使这样也不完整，我最近还没有花时间研究这个问题。
虽然算法在我看来是正确的方法，但许多人故意不使用它们。我发现人们已经取代了算法的使用情况，因为据说编写循环执行操作比调用算法更“可读”。不幸的是，在某些情况下，这确实是正确的，因为所涉及的功能对象只是丑陋的。鉴于很少有人似乎使用算法，似乎没有动力去改变它们。

Answer 2

如果要在不预先分配元素的情况下将结果放入容器中，请使用插入迭代器。例如：

std::vector<int> elements;
// ...
std::vector<int> uniqueElements;
std::unique_copy(elements.begin(), elements.end(),
    std::back_inserter(uniqueElements));

Answer 3

采用迭代器的算法是最通用的。没有什么可以阻止您创建自己的便利函数，使用适当的参数调用标准算法。

为什么std :: algorithms也不直接在容器上工作？

3 个答案: