Iterators aren’t the problem, they just enable it

The post presenting the failure case for iterators contrasted this simple Python list comprehension:

The genius insight behind iterators

The story so far:

Lambdas: Typical use cases

My last post, highlighting the differences between C++ lambdas and the lambdas in languages based upon functional programs, went more deeply into the weeds than I had intended. I realized too late that it cried out for examples. The rules for declaring free variables (the member variables of the anonymous class) in C++ lambdas can seem contorted but most uses of them fall into one of a few simple types. In this post, I want to present three simple use cases of C++ lambdas, each demonstrating a different way to use free variables.

Lambdas: Sweet, sweet syntactic sugar

Update: The next post provides recipes for common use cases of lambdas. If parts of this post seem too abstract, you might find the examples in the next post clarify things.

STL iterators and algorithms really can’t be discussed without also talking about lambdas. Although the STL design predates the introduction of lambdas by almost two decades, the introduction of lambdas in C++ 2011 improved the usability of STL algorithms substantially. I don’t have statistics but I presume that the STL algorithms now receive substantially more use due to the greater simplicity of passing callbacks as lambdas rather than instances of named classes. Lambdas are purely a matter of convenience—they introduce nothing to the language that you couldn’t do before—but by making common use cases more convenient, they effectively extend the range of use cases where calling a standard algorithm makes sense.

Iterators: A failure case

In my first post on iterators, I presented a case where they work well. In this post, I’ll present a clear failure and begin discussing why the deep structure of the design leads to this failure.