Brain Unrolling: Generators and the Sweet Syntactic Sugar of Coroutines

http://videocortex.io/2019/Brain-Unrolling/

by matt_d • 7 years ago

59 10 7 years ago

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?

deckar01• 7 years ago

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.

m6w62• 7 years ago

Previous related submission:

m6w62• 7 years ago

Stackful Coroutines (Boost.Asio) - http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/ove...

gchamonlive• 7 years ago

in the a simplified Bresenham variant function, where does dx come from?

Sophistifunk• 7 years ago

I'm going to take a wild stab here (closed the tab), but dx is usually x2-x1 (aka, distance in x)

pmiller2• 7 years ago

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.

fyp• 7 years ago

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?

swsieber• 7 years ago

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.

je42• 7 years ago

try your for loops and equivalents in godbolt.org with different C++ compilers.

Brain Unrolling: Generators and the Sweet Syntactic Sugar of Coroutines

Related Stories