对 for 构造中的第二个表达式使用 size() 总是不好的吗？

Question

在下面的示例中，我是否应该期望每次循环都会调用values.size()？在这种情况下，引入一个临时的vectorSize 变量可能是有意义的。或者现代编译器是否应该能够通过识别向量大小不能改变来优化调用。

double sumVector(const std::vector<double>& values) {
    double sum = 0.0;
    for (size_t ii = 0; ii < values.size(); ++ii) {
        sum += values.at(ii);
    }
}

请注意，我不在乎是否有更有效的方法来对向量的内容求和，这个问题只是关于在 for 构造中使用 size()。

Answer 1

这是一种明确的方法 - size() 只被调用一次。

for (size_t ii = 0, count = values.size();  ii < count;  ++ii)

编辑：我被要求实际回答这个问题，所以这是我最好的选择。

编译器通常不会优化函数调用，因为它不知道从一次调用到下一次调用是否会获得不同的返回值。如果循环内有无法预测副作用的操作，它也不会优化。内联函数可能会有所作为，但没有任何保证。局部变量更容易被编译器优化。

有些人会称之为过早优化，我同意在少数情况下您会注意到速度差异。但是，如果它不会使代码更难理解，为什么不将其视为最佳实践并采用它呢？肯定不会痛的。

附：我在仔细阅读Benoit's 答案之前写了这篇文章，我相信我们完全同意。

Answer 2

这完全取决于向量的实现大小、编译器的激进程度以及它是否侦听/使用内联指令。

我会更具防御性并引入临时性，因为您无法保证编译器的效率。

当然，如果这个例程被调用一两次，并且向量很小，那真的没关系。

如果它会被调用数千次，那么我会使用临时的。

有些人可能称之为过早优化，但我倾向于不同意这种评估。
当您尝试优化代码时，您并没有投入时间或以性能的名义混淆代码。

我很难将重构视为优化。但说到底，这就是“你说番茄，我说番茄”……

Answer 3

从“for”结构中的 size() 开始，直到您需要优化速度。

如果太慢，想办法让它更快，比如使用临时变量来保存大小的结果。

Answer 4

无论优化设置如何，将 .size() 调用放在第二个表达式中最多与在 for 循环之前概述 .size() 调用一样高效。那就是：

size_t size = values.size();
for (size_t ii = 0; ii < size; ++ii) {
    sum += values.at(ii)
}

将始终表现得至少和以下一样好，如果不是更好的话：

for (size_t ii = 0; ii < values.size(); ++ii) {
    sum += values.at(ii);
}

实际上，这可能无关紧要，因为概述 .size() 调用是一种常见的编译器优化。不过，我确实发现第二个版本更易于阅读。

不过，我发现这更容易：

double sum = std::accumulate(values.begin(), values.end(), 0);

Answer 5

值得注意的是，即使您要处理数百万个项目，开销也可以忽略不计。

在任何情况下，这都应该使用迭代器来编写 - 因为访问特定示例可能会有更多开销。

编译器真的不可能假设 size() 不会改变 - 因为它可以做到..

如果迭代的顺序不重要，那么您总是可以将其写成稍微更有效的方式。

for (int i=v.size()-1; i>=0 ;i--)
{
   ...
}

Answer 6

这不是问题的一部分，但您为什么在代码中使用 at 代替下标运算符 []？

at 的含义是确保不会发生对无效索引的操作。但是，在您的循环中永远不会出现这种情况，因为您从代码中知道索引将是什么（总是假设单线程）。

即使如果您的代码包含逻辑错误，导致您访问无效元素，at 在这个地方将毫无用处，因为您不希望出现异常，因此您不会t 对待它（或者你是否用try 块将你的循环所有括起来？）。

这里使用at 具有误导性，因为它告诉读者您（作为程序员）不知道索引将具有什么值——这显然是错误的。

我同意 Curro 的观点，这是使用迭代器的典型案例。虽然这更冗长（至少如果你不使用像 Boost.Foreach 这样的结构），但它也更具表现力和安全性。

Boost.Foreach 允许您编写如下代码：

double sum = 0.0;
foreach (double d, values)
    sum += d;

此操作安全、高效、简短、易读。

Answer 7

这根本不重要。 .at() 的性能开销非常大（它包含一个条件抛出语句），以至于非优化版本将大部分时间都花在那里。一个足够聪明以消除条件抛出的优化编译器必然会发现 size() 不会改变。

Answer 8

我同意 Benoit 的观点。引入一个新变量，尤其是一个 int 甚至是一个 short 将比每次调用它有更大的好处。

如果循环变得足够大以致可能影响性能，那就不用担心了。

Answer 9

如果你将向量的大小保存在一个临时变量中，你将独立于编译器。

我的猜测是，大多数编译器都会以某种方式优化代码，即 size() 只会被调用一次。但是使用临时变量会给你一个保证，size() 只会被调用一次！

Answer 10

std::vector 的 size 方法应该由编译器内联，这意味着每次对 size() 的调用都被它的实际主体替换（有关内联的更多信息，请参阅问题 Why should I ever use inline code）。由于在大多数实现中 size() 基本上计算 end() 和 begin() 之间的差异（也应该内联），因此您不必太担心性能损失。

此外，如果我没记错的话，一些编译器足够“聪明”，可以在 for 构造的第二部分检测表达式的常量性，并生成只对表达式求值一次的代码。

Answer 11

编译器不会知道 .size() 的值是否在调用之间发生变化，因此它不会进行任何优化。我知道您刚刚询问了 .size() 的使用，但无论如何您都应该使用迭代器。

std::vector<double>::const_iterator iter = values.begin();
for(; iter != values.end(); ++iter)
{
    // use the iterator here to access the value.
}

在这种情况下，对 .end() 的调用类似于您使用 .size() 公开的问题。如果您知道循环不会在向量中执行任何使迭代器无效的操作，则可以在进入循环之前将迭代器初始化到 .end() 位置并将其用作边界。

Answer 12

始终按照您的意思在第一次编写代码。如果您正在从零迭代向量到 size()，请这样写。不要将 size() 调用优化为临时变量，除非您已将调用分析为程序中需要优化的瓶颈。

一个好的编译器很可能会优化掉对 size() 的调用，特别是考虑到向量被声明为 const。

Answer 13

如果您使用的容器中 size() 为 O(n)（如 std::list）而不是 O(1)（如 std::vector），则不会使用索引遍历该容器。您将改用迭代器。

无论如何，如果循环的主体是如此微不足道，以至于重新计算 std::vector::size() 很重要，那么无论它是什么，都可能有一种更有效（但可能特定于平台）的方法来进行计算。如果循环体很重要，那么每次重新计算 std::vector::size() 不太重要。

Answer 14

• 如果您在 for 循环中修改向量（添加或删除元素），则不应使用临时变量，因为这可能会导致错误。
• 如果您没有在 for 循环中修改向量大小，那么我会一直使用临时变量来存储大小（这将使您的代码独立于 vector::size 的实现细节。

Answer 15

在这种情况下，使用迭代器更简洁——在某些情况下甚至更快。对容器只有一次调用 - 如果有任何剩余，则让迭代器持有指向向量成员的指针，否则为 null。

那么for 当然可以变成while 并且根本不需要临时变量 - 您甚至可以将迭代器传递给 sumVector 函数而不是 const 引用/值。

Answer 16

size() 的大多数，甚至可能是所有的标准实现将被编译器内联到相当于临时或最多指针取消引用的内容。

但是，您永远无法确定。内联就像这些东西一样隐藏，并且第 3 方容器可能有虚函数表 - 这意味着您可能不会被内联。

但是，说真的，使用临时变量会稍微降低可读性，几乎可以肯定没有任何好处。如果分析表明它是富有成效的，那么只优化到一个临时的。如果您在各处进行这些微优化，您的代码可能会变得不可读，甚至对您自己来说也是如此。

顺便说一句，没有编译器会将 size() 优化为分配给临时的调用之一。 C++ 中几乎没有 const 的保证。编译器不能冒险假设 size() 将为整个循环返回相同的值。例如。另一个线程可以在循环迭代之间更改向量。