基于范围的“ for”循环是否不赞成使用许多简单算法？

算法解决方案：

std::generate(numbers.begin(), numbers.end(), rand);

基于范围的for循环解决方案：

for (int& x : numbers) x = rand();

为什么我要std::generate在C ++ 11中使用比基于范围的for循环更详细的信息？

第一个版本

std::generate(numbers.begin(), numbers.end(), rand);

告诉我们您要生成一个值序列。

在第二版中，读者必须自己弄清楚这一点。

节省键入时间通常不是最佳选择，因为它通常会浪费在阅读时间上。多数代码读取的内容远远超过其键入的内容。

无论for循环是否基于范围，都没有任何区别，它仅简化了括号内的代码。算法更清晰，因为它们表明了意图。

我个人最初阅读以下内容：

std::generate(numbers.begin(), numbers.end(), rand);

是“我们正在分配范围内的所有内容。范围是numbers。分配的值是随机的”。

我的初步阅读：

for (int& x : numbers) x = rand();

是“我们正在对范围内的所有内容执行操作。范围是numbers。我们要做的是分配随机值。”

这些非常相似，但不完全相同。我可能想引起一读的一个可能的原因是，因为我认为有关此代码的最重要事实是它分配给该范围。所以有您的“我为什么要...”。我使用generateC ++std::generate是因为“范围分配”。就像btw一样std::copy，两者之间的区别就是您要从中进行分配。

不过，还有一些混杂因素。与基于numbers迭代器的算法相比，基于范围的for循环本质上更直接地表示范围为。这就是为什么人们使用基于范围的算法库的原因：boost::range::generate(numbers, rand);看起来比std::generate版本更好。

与此相反，int&在基于范围的for循环中会出现皱纹。如果范围的值类型不是int，那我们将在此做一些令人讨厌的微妙工作，这取决于它是否可以转换为int&，而generate代码仅取决于rand可分配给元素的返回。即使值类型是int，我仍然可能会停止考虑它是否是。因此auto，推迟了对类型的思考，直到我看到要分配的内容为止-auto &x我说“请引用range元素，无论可能具有什么类型”。早在C ++ 03，算法（因为它们是函数模板）都将隐藏确切类型的方式，现在他们一个方式。

我认为，一直以来，最简单的算法仅比等效循环具有边际优势。基于范围的for循环可改善循环（主要是通过删除大部分样板，尽管它们要多得多）。因此，利润越来越紧，在某些特定情况下，您可能会改变主意。但是那里仍然存在风格差异。

在我看来，有效的STL项目43：“首选算法调用优先于手写循环。” 仍然是一个很好的建议。

我通常编写包装函数来摆脱begin()/ end()hell。如果这样做，您的示例将如下所示：

my_util::generate(numbers, rand);

我认为它在传达意图和可读性方面都超过了for循环的范围。

话虽如此，我必须承认，在C ++ 98中，某些STL算法调用产生了无法言喻的代码，并且遵循“首选对手写循环的算法调用”似乎不是一个好主意。幸运的是，lambda改变了这一点。

考虑来自Herb Sutter的以下示例：Lambdas，Lambdas Everywhere。

任务：在v中找到第一个元素是> x和< y。

没有lambda：

auto i = find_if( v.begin(), v.end(),
bind( logical_and<bool>(),
bind(greater<int>(), _1, x),
bind(less<int>(), _1, y) ) );

带lambda

auto i=find_if( v.begin(), v.end(), [=](int i) { return i > x && i < y; } );

在我看来，人工循环，但可能会减少冗长，缺乏readabitly：

for (int& x : numbers) x = rand();

我不会使用此循环来初始化¹由数字定义的范围，因为当我看它时，似乎在一个数字范围内进行迭代，但是实际上它并没有（本质上），即不是从范围读取，它正在写入范围。

使用时意图更加清晰std::generate。

^{1.在这种情况下，初始化意味着为容器的元素赋予有意义的值。}

对于基于范围的循环，有些事情是您做不到的（简单地），而将迭代器作为输入的算法则可以做到。例如std::generate：

使用一个发行版中的变量填充容器limit（不包括limit上的有效迭代器numbers），而使用另一个发行版中的变量填充容器。

std::generate(numbers.begin(), limit, rand1);
std::generate(limit, numbers.end(), rand2);

基于迭代器的算法可让您更好地控制要操作的范围。

对于的特殊情况std::generate，我同意先前关于可读性/意图问题的答案。std :: generate在我看来似乎更清晰。但是我承认这在某种程度上是一种品味问题。

就是说，我还有另一个理由不放弃std :: algorithm-有些算法专门针对某些数据类型。

最简单的示例是std::fill。通用版本被实现为提供范围内的for循环，并且在实例化模板时将使用该版本。但不总是。例如，如果您提供一个范围std::vector<int>-通常它实际上会在后台调用memset，从而产生更快，更好的代码。

所以我想在这里打一个效率卡。

您的手写循环可能和std :: algorithm版本一样快，但是几乎不可能更快。不仅如此，std :: algorithm可能专门用于特定的容器和类型，并且是在干净的STL接口下完成的。

我的答案可能是，否。如果我们在谈论C ++ 11，那么也许（更像是没有）。例如std::for_each，即使与lambda一起使用也很烦人：

std::for_each(c.begin(), c.end(), [&](ExactTypeOfContainedValue& x)
{
    // do stuff with x
});

但是使用基于范围的for会更好：

for (auto& x : c)
{
    // do stuff with x
}

另一方面，如果我们谈论的是C ++ 1y，那么我认为不可以，基于范围的for不会淘汰这些算法。在C ++标准委员会中，有一个研究小组正在研究将范围添加到C ++的提案，并且还在处理多态lambda。范围将消除使用迭代器对的需要，而多态lambda将使您不必指定lambda的确切参数类型。这意味着std::for_each可以这样使用（不要把这个当成困难的事实，这就是今天的梦想）：

std::for_each(c.range(), [](x)
{
    // do stuff with x
});

应该注意的一件事是，一种算法表示完成的事情，而不是如何完成的事情。

基于范围的循环包括完成操作的方式：从第一个开始，应用并转到下一个元素，直到结束。即使是简单的算法也可以做不同的事情（至少对于特定容器有些重载，甚至不考虑可怕的向量），并且至少完成方法不是编写者事务。

对我来说，最大的不同是，尽可能地封装，并在可能的情况下使用算法证明句子的合理性。

基于范围的for循环就是这样。当然，直到标准被更改为止。

算法是一种功能。对参数有一些要求的函数。这些要求以标准的措辞表达，以允许利用所有可用执行线程的示例实现，并将自动加快您的速度。