for 循环内的迭代器初始化是否被认为是不好的风格，为什么？

Question

通常，您会发现如下所示的 STL 代码：

for (SomeClass::SomeContainer::iterator Iter = m_SomeMemberContainerVar.begin(); Iter != m_SomeMemberContainerVar.end(); ++Iter)
{
}

但我们实际上建议这样编写：

SomeClass::SomeContainer::iterator Iter = m_SomeMemberContainerVar.begin();
SomeClass::SomeContainer::iterator IterEnd = m_SomeMemberContainerVar.end();
for (; Iter != IterEnd; ++Iter)
{
}

如果您担心范围界定，请添加大括号：

{
    SomeClass::SomeContainer::iterator Iter = m_SomeMemberContainerVar.begin();
    SomeClass::SomeContainer::iterator IterEnd = m_SomeMemberContainerVar.end();
    for (; Iter != IterEnd; ++Iter)
    {
    }
}

这应该会提高速度和效率，尤其是在您对控制台进行编程时，因为 .end() 函数不会在循环的每次迭代中调用。 我只是认为性能改进是理所当然的，这听起来很合理，但我不知道有多少，而且它肯定取决于容器的类型和实际使用的 STL 实现。 但在使用这种风格几个月后，我实际上更喜欢它而不是第一种。

原因是可读性：for 行干净整洁。 使用实际生产代码中的限定符和成员变量，如果您使用第一个示例中的样式，则很容易使行真正很长。 这就是为什么我在这个例子中故意让它有一个水平滚动条，这样你就能明白我在说什么。 ;)

另一方面，您突然将 Iter 变量引入 for 循环的外部范围。 但是，至少在我工作的环境中，即使在第一个示例中，Iter 也可以在外部范围内访问。

你对此有什么看法？ 除了可能限制 Iter 的范围之外，第一种风格还有什么优点吗？

Answer 1

如果您正确地将代码包装成行，则内联表单将同样具有可读性。 此外，您应该始终执行 iterEnd = container.end() 作为优化：

for (SomeClass::SomeContainer::iterator Iter = m_SomeMemberContainerVar.begin(),
    IterEnd = m_SomeMemberContainerVar.end();
    Iter != IterEnd;
    ++Iter)
{
}

更新：根据 paercebal 的建议修复代码。

Answer 2

另一种选择是使用 foreach 宏，例如 boost foreach：

BOOST_FOREACH( ContainedType item, m_SomeMemberContainerVar )
{
   mangle( item );
}

我知道在现代 C++ 中不鼓励使用宏，但是在 auto 关键字广泛使用之前，这是我发现的获得简洁和可读的东西的最佳方法，并且仍然完全类型安全和快速。 您可以使用任何可以获得更好性能的初始化样式来实现宏。

链接页面上还有一条关于将 BOOST_FOREACH 重新定义为 foreach 以避免烦人的全大写的注释。

Answer 3

如果 for 循环之后不需要迭代器，则第一种形式（在 for 循环内）更好。 它将其范围限制为 for 循环。

我严重怀疑这两种方式是否能提高效率。 还可以使用 typedef 使其更具可读性。

typedef SomeClass::SomeContainer::iterator MyIter;

for (MyIter Iter = m_SomeMemberContainerVar.begin(); Iter != m_SomeMemberContainerVar.end(); ++Iter)
{
}

我会推荐较短的名称;-)

Answer 4

在 g++ 的 -O2 优化中查看了这一点（只是具体而言），

std::vector、std::list 和 std::map（和朋友）的生成代码没有区别。 std::deque 的开销很小。

所以一般来说，从性能的角度来看，这没有什么区别。

Answer 5

不，在循环开始之前保留 iter.end() 不是一个好主意。 如果循环更改容器，则结束迭代器可能会失效。 此外，end() 方法保证为 O(1)。

过早的优化是万恶之源。

而且，编译器可能比你想象的更聪明。

Answer 6

尽管迭代器生命周期会让我倾向于 for 作用域版本，但我对其中一种方式没有特别强烈的意见。

然而，可读性可能是一个问题； 这可以通过使用 typedef 来帮助，这样迭代器类型更易于管理：

typedef SomeClass::SomeContainer::iterator sc_iter_t;

for (sc_iter_t Iter = m_SomeMemberContainerVar.begin(); Iter != m_SomeMemberContainerVar.end(); ++Iter)
{
}

不是一个巨大的改进，但有一点。

Answer 7

我没有任何控制台经验，但在大多数现代 C++ 编译器中，除了范围问题之外，这两个选项最终都是等效的。 即使在调试代码中，Visual Studio 编译器实际上也总是将条件比较放在隐式临时变量（通常是寄存器）中。 因此，虽然逻辑上看起来每次迭代都会进行 end() 调用，但优化的编译代码实际上只进行一次调用，并且比较是循环中每次后续时间执行的唯一操作。

在控制台上可能不是这种情况，但您可以拆开循环来检查优化是否正在发生。 如果是，那么您可以采用您喜欢的或组织中标准的任何风格。

Answer 8

它可能会导致代码脱节，但我也喜欢将其提取到一个单独的函数中，并将两个迭代器传递给它。

doStuff(coll.begin(), coll.end())

并且有..

template<typename InIt>
void doStuff(InIt first, InIt last)
{
   for (InIt curr = first; curr!= last; ++curr)
   {
       // Do stuff
   }
 }

喜欢的事情：

• 不必提及丑陋的迭代器类型（或考虑它是const还是not-const）
• 如果在每次迭代时不调用end()有好处，我就明白了

永远 就像：

• 代码
• 分解额外函数调用的

开销。 但有一天，我们将会拥有 lambda！

Answer 9

我认为这根本不是不好的风格。 只需使用 typedef 即可避免 STL 的冗长和长行。

typedef set<Apple> AppleSet;
typedef AppleSet::iterator  AppleIter;
AppleSet  apples;

for (AppleIter it = apples.begin (); it != apples.end (); ++it)
{
   ...
}

斯巴达式编程是减轻风格问题的一种方法。

Answer 10

如果您担心范围，可以在初始化和循环周围添加大括号。 通常我会做的是在函数的开头声明迭代器并在整个程序中重用它们。

Answer 11

我同意费鲁吉奥的观点。 有些人可能更喜欢第一种样式，以便将 end() 调用拉出循环。

我还可以补充一点，C++0x 实际上会使两个版本更加清晰：

for (auto iter = container.begin(); iter != container.end(); ++iter)
{
   ...
}

auto iter = container.begin();
auto endIter = container.end();
for (; iter != endIter; ++iter)
{
   ...
}

Answer 12

我通常会写：

SomeClass::SomeContainer::iterator Iter = m_SomeMemberContainerVar.begin(),
                                   IterEnd = m_SomeMemberContainerVar.end();

for(...)

Answer 13

我发现第二个选项更具可读性，因为您最终不会得到一大行。 然而，费鲁吉奥提出了关于范围的一个很好的观点。