5 ms·

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

by cheepin 12y ago

lobo_tuerto 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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

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

by cheepin 12y ago

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 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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