take(5): Using the C++ Iterator Model to Take Elements from an Input Stream - Barry Revzin - CppNow

[@russCoding]

Thank you Barry Revzin for the informative talk. I and many in the C++ community appreciate the hard work you've done over the years to improve the language and support the community by answering questions and helping to address concerns. One comment is that I think this video was sped up about 120%, so I ended up watching it on 0.8x speed. 🤷

[@SamWhitlock]

51:00 sometimes I get the feeling that views, though useful, still force one to mentally "unroll" the abstraction to raw underlying iterators. I still am glad they're in the language (despite the issues Nico pointed out in his talk), but they really aren't as ergonomic as other languages that are supported by a runtime :(

[@27182818284590452354]

So much effort is spent on trying to fit a square piece into a circular hole. Why don't we just agree that a pair of STL iterators is not a proper interface for some tasks of set traversal? Since we end up with even more ways to do the same, shouldn't we make the new way not only sensible in itself, but purposefully distinct to avoid confusion?

[@squarerootof2]

So irrational.

[@NoNameAtAll2]

so, to summarize - input iterators (one pass/generate on demand ones) need to cache element it's gonna output/it's pointing to - range operations leave iterators in "one past last used element" state (".end()") input iterators pretty much "read past the last element"? take(5) example shows that ".end()" value gets consumed into cache, but not returned in any way iota-filter shows example where "reading .end()" results in endless loop std::istream family deal with that via failure flags, because "file/string ran out" is easy to detect but iota-filter can't do that

[@HuyNguyen-fq4rh]

Is his code better than a G-code parser?

[@Messmerd97]

Stuff like this makes me question the value of range pipelines. They look simple and cool and all, but they bring so much unintuitive behavior that it seems you need a strong understanding of their implementation details before you can use them correctly and efficiently. At that point, why bother?

[@simonfarre4907]

The simplicity of Rust's iterators and views are looking more and more appealing.

[@NoNameAtAll2]

but iterator model isn't the problem, tho?

[@germanassasin1046]

@@NoNameAtAll2 It is kinda. In rust increment and dereference of the iterator are unified in one operation called next, so you can just extract the element there without any "dirty" flags.