Demystifying C++ lambdas
blog.feabhas.com
blog.feabhas.com
Abstraction inversion. Lambda is a much simpler idea than all this C++ stuff used to explain it. Languages should have lambda first, and bullshit like "functor classes" second, if at all.
If you are explaining it to a seasoned C++-only programmer it makes sense to explain lambdas in terms of other C++ features. Even more if lambdas are based internally on said features.
If I were to explain classes as "Suppose you have a struct, and a set of functions that were required to have that struct as their first argument", then classes wouldn't seem to have a point.
If I were to explain polymorphism as "Suppose you have a table of function pointers in each struct, and whenever you want to call a function, you first look it up", then virtual function pointers wouldn't seem to have a purpose.
> Good Scheme compilers use a range of implementations for the lambdas in the program, depending upon what they can determine about the lambdas at compile time -- how they're used, to where they are passed, the relationship between the uses and the definition points, etc. Some lambdas just evaporate into nothing. Some lambdas turn into control-flow join points with associated register/variable bindings. Some lambdas turn into stack frames. But some lambdas cause heap allocation to produce general closures.
Of course, C++ is hugely impacted by its legacy burden. Any newer language would probably do it in a simpler way. Still, the fact that lambdas and objects use the same scope makes things much easier to understand remember.