Brain Unrolling: Generators and the Sweet Syntactic Sugar of Coroutines(videocortex.io)
videocortex.io
Brain Unrolling: Generators and the Sweet Syntactic Sugar of Coroutines
http://videocortex.io/2019/Brain-Unrolling/
4 comments
I love generators in python/javascript/etc but nowadays whenever I reach for C++ it's because I need performance. What's the cost of using this abstraction? Are compilers smart enough to convert the equivalent of "for i in range(n)" from python into a regular for loop?
I don't know.
Fun tidbit about Rust: in Rust, using iterators is actually faster than normal loops because the compiler can elide (infer and remove? not entirely sure how to define elude), most of the bounds checking.
I'd assume it also gets optimized out in heavily optimized interpreters, like the JVM.
Fun tidbit about Rust: in Rust, using iterators is actually faster than normal loops because the compiler can elide (infer and remove? not entirely sure how to define elude), most of the bounds checking.
I'd assume it also gets optimized out in heavily optimized interpreters, like the JVM.
try your for loops and equivalents in godbolt.org with different C++ compilers.
The author has done a really good overview here, however (perhaps by virtue of the example being too simple), the resulting code looks much less readable than the original code. Which I guess goes to say, there are probably situations where it is appropriate to use stuff like this and situations where it could be easily abused?
I think of it like streams vs strings. When you are writing a one-off script, reading an entire file into a string in memory is fine. When you are writing a library and need to handle files in the wild, you are going to read the file in chunks and process them as a stream. Generators are like streams for iterables. You don't usually write code that manually builds streams. Likewise, you generally will not write generators that manually yield values. The standard library will provide a collection of tools that make the operations you were already performing on collections more memory efficient by using generators to avoid intermediate buffers.
in the a simplified Bresenham variant function, where does dx come from?
I'm going to take a wild stab here (closed the tab), but dx is usually x2-x1 (aka, distance in x)
I agree dx=x1-x0 would make sense, but dx isn’t actually defined in the code from what I see. I think that’s why the GP poster is confused.
Previous related submission:
Stackful Coroutines (Boost.Asio) - http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/ove...