c++ - 为什么 std::algorithms 不能直接在容器上工作？

Question

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

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

我肯定有我不知道的充分理由？

Answer 1

我认为有两个主要原因:

1. 为容器添加重载会使函数数量增加一倍以上:对于每个只取一个范围的算法，重载会增加一倍。但是，对于像 std::copy() 这样的东西，您有两个范围，每个范围都希望独立地指定为范围(正确的抽象不是容器，顺便说一句，而是护林员)或一对迭代器，使其已经有 4 个重载。
2. 一旦范围进入画面，就不再完全清楚需要返回什么。您的示例使用 std::find() ，它在获取迭代器作为参数时明确返回迭代器。当给定一个范围时，返回另一个范围实际上可能更合理。更糟糕的是，除非您最初只有一个通过范围(例如，从流中读取的内容)，否则甚至可以选择两个不同的范围，即从开始找到对象，到找到对象结束。另一个维度可能是选择获取所选范围的拷贝，而不是获取由迭代器分隔的范围。

当初提出STL的时候，一开始被认为是Crazy Talk!试图说服人们打开另一个主要的蠕虫 jar 头来正确处理范围可能很容易扼杀整个想法。紧接着的后续问题变成了:为什么这没有改变？ ... 这个问题也有两个答案:

1. 虽然在我将草稿提交给图书馆工作组时被认为是合理的，但我并未提议更改界面。然而，我概述的提议并没有受到热烈欢迎。此外，当时我不知道如何以可接受的努力实际实现我设想的接口(interface)(我知道如何使用 C++ 2011 功能)。我已经开始写一个description of a new interface of STL但即使这样也不完整，我最近没能抽出时间来处理这个问题。
2. 虽然在我看来算法是正确的方法，但许多人故意不使用它们。我发现人们已经替换了算法的使用，因为据称编写循环执行操作比调用算法“更具可读性”。不幸的是，在某些情况下确实如此，因为所涉及的函数对象非常可怕。鉴于似乎很少有人使用这些算法，因此似乎没有动力去改变它们。