
Demystifying C++ lambdas - SirOibaf
http://blog.feabhas.com/2014/03/demystifying-c-lambdas/
======
cousin_it
> _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.

~~~
cheepin
Lambdas are not particularly complicated, but the way to make them simple is
to compare to other language's implementation, not other C++ features.

~~~
lobo_tuerto
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.

~~~
MereInterest
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.

~~~
renox
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..

~~~
cousin_it
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](http://www.paulgraham.com/thist.html)

------
zschoche
In most cases, lambdas are rvalues. That can have an impact on its scope and
lifetime.

