Demystifying C++ lambdas(blog.feabhas.com)
blog.feabhas.com
Demystifying C++ lambdas
http://blog.feabhas.com/2014/03/demystifying-c-lambdas/
2 comments
In most cases, lambdas are rvalues. That can have an impact on its scope and lifetime.
> Basically, lambdas are syntactic sugar, designed to reduce a lot of the work required in creating ad-hoc functor classes.
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.
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.
I disagree. It's easier to comprehend the scope and lifetime of bound variables and lambdas if you already know them from normal objects. I had a hard time to grasp the lifetime of my lambdas and how the variables were bound, stored and passed to a function.
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.
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.
C++ lambdas are not CS-theory lambdas and they're (by definition) syntax sugar for the functor-class bullshit they're described as in the article.
Lambdas are not particularly complicated, but the way to make them simple is to compare to other language's implementation, not other C++ features.
It depends on who are you explaining it to.
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 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.
I'd disagree there. If you explain it only in terms of what is already there, then the question "So why bother?" comes up.
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.
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.
OTOH if you only explain why you add this feature and not how it is done, then
1) the 'magic' sense of the feature may bother developers who likes to know how things work
2) you don't understand the limitations of the feature linked to the implementation.
So both how and why are needed, me I prefer an explanation of 'how works X' before 'why use X', a short 'why' followed by 'how it is implemented' and a more detailed 'why' is best but YMMV..
I agree that users of a programming language should understand the implementations and costs of its abstractions. That said, I think lambda is an important enough abstraction that it should just work as the math says, without arbitrary limitations. Anything less than that is a point against the language. This paragraph from "History of T" [1] is interesting:
> 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.
[1] http://www.paulgraham.com/thist.html
> 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.
[1] http://www.paulgraham.com/thist.html