以下面两行代码为例:
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
}
有人告诉我第二种方法更可取。为什么会这样呢?
以下面两行代码为例:
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
}
有人告诉我第二种方法更可取。为什么会这样呢?
当前回答
这是现代c++灌输过程的一部分。迭代器是迭代大多数容器的唯一方法,所以即使对向量也使用迭代器,只是为了让自己进入正确的心态。说真的,这是我这么做的唯一原因——我不认为我曾经用不同类型的容器替换过一个向量。 哇,三周之后,还是有人投反对票。我想开玩笑是不值得的。
我认为数组索引可读性更好。它与其他语言中使用的语法以及老式C数组所使用的语法相匹配。它也更简洁。如果你的编译器有任何好的地方,效率应该是一个洗涤,而且几乎没有任何情况下,它是重要的。
即便如此,我仍然发现自己经常对向量使用迭代器。我相信迭代器是一个重要的概念,所以我尽可能地推广它。
其他回答
我在这里是魔鬼的倡导者,不推荐使用迭代器。主要原因是,我从桌面应用程序开发到游戏开发的所有源代码都没有我也不需要使用迭代器。一直以来,迭代器都不是必需的,其次,迭代器所带来的隐藏假设、代码混乱和调试噩梦,使其成为任何要求速度的应用程序都不要使用的典型例子。
即使从维护的角度来看,它们也是一团糟。这并不是因为它们,而是因为所有发生在幕后的混叠。我怎么知道你没有实现你自己的虚拟向量或数组列表,做一些完全不同的标准。我知道什么类型的当前,现在在运行时?你是否重载了运算符我没有时间检查你所有的源代码。我甚至不知道你使用的STL是什么版本?
迭代器的下一个问题是抽象漏洞,尽管有许多网站对此进行了详细讨论。
对不起,我没有,现在也没有看到迭代器有任何意义。如果他们抽象了列表或向量,而实际上你应该已经知道你要处理什么向量或列表,如果你不知道,那么你只会为将来的一些伟大的调试会话做好准备。
因为它更面向对象。如果你用一个索引迭代,你假设:
A)这些对象是有序的 B)这些对象可以通过索引获得 C)索引增量会影响每一项 D,指数从零开始
使用迭代器,你是在说“给我所有东西,这样我就可以使用它”,而不知道底层实现是什么。(在Java中,有些集合不能通过索引访问)
此外,使用迭代器,无需担心超出数组的边界。
如果你可以访问c++ 11的特性,那么你也可以使用一个基于范围的for循环来迭代你的vector(或任何其他容器),如下所示:
for (auto &item : some_vector)
{
//do stuff
}
这个循环的好处是,您可以直接通过item变量访问vector的元素,而不会有搞乱索引或在解引用迭代器时出错的风险。此外,占位符auto可以防止您重复容器元素的类型, 这使您更接近于容器无关的解决方案。
注:
如果您需要循环中的元素索引,并且容器中存在操作符[](并且对您来说足够快),那么最好采用第一种方法。 基于范围的for循环不能用于在容器中添加/删除元素。如果你想这样做,那么最好坚持布莱恩·马修斯给出的解决方案。 如果你不想改变容器中的元素,那么你应该如下所示使用关键字const: for (auto const &item: some_vector){…}。
在对这个问题有了更多的了解之后,我意识到这有点过于简单化了。这个循环的区别是:
for (some_iterator = some_vector.begin(); some_iterator != some_vector.end();
some_iterator++)
{
//do stuff
}
这个循环:
for (int i = 0; i < some_vector.size(); i++)
{
//do stuff
}
相当小。事实上,这样做循环的语法似乎越来越适合我:
while (it != end){
//do stuff
++it;
}
迭代器确实解锁了一些相当强大的声明性特性,当与STL算法库结合使用时,您可以做一些非常酷的事情,这些事情超出了数组索引管理的范围。
在迭代过程中,您不需要知道要处理的项目的数量。你只需要item和迭代器就能很好地完成这些事情。