以下面两行代码为例:

for (int i = 0; i < some_vector.size(); i++)
{
    //do stuff
}

这:

for (some_iterator = some_vector.begin(); some_iterator != some_vector.end();
    some_iterator++)
{
    //do stuff
}

有人告诉我第二种方法更可取。为什么会这样呢?


当前回答

假设some_vector是用链表实现的。然后,在第i个位置请求一个项需要执行i个操作来遍历节点列表。现在,如果您使用迭代器,一般来说,它将尽最大努力尽可能高效(在链表的情况下,它将维护一个指向当前节点的指针,并在每次迭代中推进它,只需要一个操作)。

所以它提供了两件事:

使用的抽象:你只想迭代一些元素,你不关心如何去做 性能

其他回答

因为它更面向对象。如果你用一个索引迭代,你假设:

A)这些对象是有序的 B)这些对象可以通过索引获得 C)索引增量会影响每一项 D,指数从零开始

使用迭代器,你是在说“给我所有东西,这样我就可以使用它”,而不知道底层实现是什么。(在Java中,有些集合不能通过索引访问)

此外,使用迭代器,无需担心超出数组的边界。

分离关注点

将迭代代码从循环的“核心”关注点中分离出来是非常好的。这几乎是一个设计决策。

实际上,通过索引迭代将您与容器的实现联系在一起。向容器请求开始和结束迭代器,使循环代码可用于其他容器类型。

同样,在std::for_each方法中,你告诉集合要做什么,而不是询问它的内部信息

0x标准将引入闭包,这将使这种方法更容易使用-看看例如Ruby的[1..6]的表达能力。每个{|i| print i;}……

性能

但是可能有一个被监督的问题是,使用for_each方法产生了一个并行迭代的机会——intel线程块可以将代码块分布在系统中的处理器数量上!

注意:在发现算法库,特别是foreach之后,我花了两三个月的时间写了非常小的“helper”操作符结构,这会让其他开发人员发疯。在这之后,我回到了一个实用的方法-小循环体不应该再有foreach了:)

关于迭代器的必读参考书是《扩展STL》。

GoF在迭代器模式的末尾有一小段话,讲的是这种迭代;它被称为“内部迭代器”。这里也看看。

我在这里是魔鬼的倡导者,不推荐使用迭代器。主要原因是,我从桌面应用程序开发到游戏开发的所有源代码都没有我也不需要使用迭代器。一直以来,迭代器都不是必需的,其次,迭代器所带来的隐藏假设、代码混乱和调试噩梦,使其成为任何要求速度的应用程序都不要使用的典型例子。

即使从维护的角度来看,它们也是一团糟。这并不是因为它们,而是因为所有发生在幕后的混叠。我怎么知道你没有实现你自己的虚拟向量或数组列表,做一些完全不同的标准。我知道什么类型的当前,现在在运行时?你是否重载了运算符我没有时间检查你所有的源代码。我甚至不知道你使用的STL是什么版本?

迭代器的下一个问题是抽象漏洞,尽管有许多网站对此进行了详细讨论。

对不起,我没有,现在也没有看到迭代器有任何意义。如果他们抽象了列表或向量,而实际上你应该已经知道你要处理什么向量或列表,如果你不知道,那么你只会为将来的一些伟大的调试会话做好准备。

STL迭代器大部分都在那里,所以STL算法,比如sort,可以是容器独立的。

如果你只是想循环遍历一个向量中的所有项,只需使用索引循环样式。

对大多数人来说,它的输入更少,更容易解析。如果c++有一个简单的foreach循环,而不是过度使用模板魔法,那就太好了。

for( size_t i = 0; i < some_vector.size(); ++i )
{
   T& rT = some_vector[i];
   // now do something with rT
}
'

第二种形式更准确地表示您正在做什么。在你的例子中,你并不关心i的值,你所需要的只是迭代器中的下一个元素。