迭代器方法和视图方法有什么区别?

发布于 2024-10-14 02:56:04 字数 289 浏览 1 评论 0原文

scala> (1 to 10).iterator.map{_ * 2}.toList
res1: List[Int] = List(2, 4, 6, 8, 10, 12, 14, 16, 18, 20)

scala> (1 to 10).view.map{_ * 2}.force
res2: Seq[Int] = Vector(2, 4, 6, 8, 10, 12, 14, 16, 18, 20)

除了使用 next、hasNext 之外,什么时候应该选择迭代器而不是视图或视图而不是迭代器?

scala> (1 to 10).iterator.map{_ * 2}.toList
res1: List[Int] = List(2, 4, 6, 8, 10, 12, 14, 16, 18, 20)

scala> (1 to 10).view.map{_ * 2}.force
res2: Seq[Int] = Vector(2, 4, 6, 8, 10, 12, 14, 16, 18, 20)

Other than using next,hasNext, when should I choose iterator over view or view over iterator?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

唐婉 2024-10-21 02:56:04

迭代器和视图之间存在巨大差异。迭代器只使用一次,按需计算,而视图则使用多次,每次都重新计算,但只计算需要的元素。例如:

scala> val list = List(1,2,3).map{x => println(x); x * 2}
1
2
3
list: List[Int] = List(2, 4, 6)

scala> list(2)
res14: Int = 6

scala> list(2)
res15: Int = 6

scala> val view = List(1,2,3).view.map{x => println(x); x * 2}
view: scala.collection.SeqView[Int,Seq[_]] = SeqViewM(...)

scala> view(2)
3
res12: Int = 6

scala> view(2)
3
res13: Int = 6

scala> val iterator = List(1,2,3).iterator.map{x => println(x); x * 2}
iterator: Iterator[Int] = non-empty iterator

scala> iterator.drop(2).next
1
2
3
res16: Int = 6

scala> iterator.drop(2).next
[Iterator.next] (Iterator.scala:29)
(access lastException for the full trace)

There's a huge difference between iterators and views. Iterators are use once only, compute on demand, while views are use multiple times, recompute each time, but only the elements needed. For instance:

scala> val list = List(1,2,3).map{x => println(x); x * 2}
1
2
3
list: List[Int] = List(2, 4, 6)

scala> list(2)
res14: Int = 6

scala> list(2)
res15: Int = 6

scala> val view = List(1,2,3).view.map{x => println(x); x * 2}
view: scala.collection.SeqView[Int,Seq[_]] = SeqViewM(...)

scala> view(2)
3
res12: Int = 6

scala> view(2)
3
res13: Int = 6

scala> val iterator = List(1,2,3).iterator.map{x => println(x); x * 2}
iterator: Iterator[Int] = non-empty iterator

scala> iterator.drop(2).next
1
2
3
res16: Int = 6

scala> iterator.drop(2).next
[Iterator.next] (Iterator.scala:29)
(access lastException for the full trace)
聆听风音 2024-10-21 02:56:04

view 生成一个惰性集合/流。它的主要魅力在于它不会尝试构建整个集合。当您只需要集合中的前几个项目时,这可以防止 OutOfMemoryError 或提高性能。 iterator 不做这样的保证。

还有一件事。至少在 Range 上,view 返回一个 SeqView,它是 Seq 的子类型,因此您可以返回或从头开始并执行所有有趣的顺序操作。

我想迭代器和视图之间的区别在于前面和后面的问题。迭代器预计会发布已经看到的内容。一旦 next 被调用,前一个就有望被释放。观点则相反。他们承诺不会获取未要求的东西。如果你有一个所有素数的视图,一个无限的集合,它只获得了你所要求的那些素数。如果你想要第 100 个,那么 101 应该还没有占用内存。

view produces a lazy collection/stream. It's main charm is that it won't try and build the whole collection. This could prevent a OutOfMemoryError or improve performance when you only need the first few items in the collection. iterator makes no such guarantee.

One more thing. At least on Range, view returns a SeqView, which is a sub-type of Seq, so you can go back or start again from the beginning and do all that fun sequency stuff.

I guess the difference between an iterator and a view is a matter of in-front and behind. Iterators are expected to release what has been seen. Once next has been called, the previous is, hopefully, let go. Views are the converse. They promise to not acquire what has not been requested. If you have a view of all prime numbers, an infinite set, it has only acquired those primes you've asked for. It you wanted the 100th, 101 shouldn't be taking up memory yet.

南街女流氓 2024-10-21 02:56:04

页面讨论何时使用视图。

总而言之,视图是调和各方关切的强大工具。
注重模块化的效率。但为了不成为
纠结延迟评估方面,你应该限制观点
分两种情况。要么在纯函数代码中应用视图
其中集合转换没有副作用。或者你
将它们应用到完成所有修改的可变集合上
明确地。最好避免混合使用视图和操作
创建新集合的同时也有副作用。

This page talks about when to use views.

In summary, views are a powerful tool to reconcile concerns of
efficiency with concerns of modularity. But in order not to be
entangled in aspects of delayed evaluation, you should restrict views
to two scenarios. Either you apply views in purely functional code
where collection transformations do not have side effects. Or you
apply them over mutable collections where all modifications are done
explicitly. What's best avoided is a mixture of views and operations
that create new collections while also having side effects.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文