Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++14 lambda tutorial

solarianprogrammer.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: C++14 lambda tutorial

#21

Post by leni536 »

guidopallemans wrote: post #13
TillE wrote: post #4

Earlier quoted context omitted.

Not shown in this article are all the things you can do within the [] (typically just [&] or [=]), which turns a simple lambda into a closure. The syntax is a bit arcane, but it does what it needs to. They could've stuck a "lambda" keyword in front of it all, but it's not necessary, and making a new keyword always has the potential to break old code.

is it possible to do #define lambda [] ?

I think you can

  #define begin {
  #define end   }
too. I would not suggest it though.

Re: C++14 lambda tutorial

#22

Post by claudius »

tdsamardzhiev wrote: post #14

I work as a C++ developer, but damn, C++ has the ugliest lambda syntax ever.

Do you have an alternative suggestion? It seems reasonably straightforward to me and I don’t find it all that impossible. Not having to muck around with a specific lambda() factory-like function with horrible inputs (as is needed in LPC where I sort-of learnt to code) is a plus :)

Re: C++14 lambda tutorial

#23

Post by rbonvall »

leni536 wrote: post #9
cengizkrbck wrote: post #2

In python, lambda usage extremly beautiful. Also, 'lambda' keyword solves readibility problem. I expected a keyword. Is there any challenge to add keyword?

I don't like that in python you are enforced to only use a single expression in lambda. Sure, writing long lambda functions is ugly but I don't think python should enforce a given coding style in the language level.

While I see the use for multi-statement lambdas, and I use them all the time in {Java,Coffee}Script, they are rarely needed in Python as there is always a more idiomatic way to write the code. In particular, with for loops and generator expressions (~list comprehensions) you can cover almost all uses of .each, .map, .filter, .some (`any` in Python), .every (`all` in Python), etc.

Re: C++14 lambda tutorial

#25

Post by repsilat »

claudius wrote: post #22
tdsamardzhiev wrote: post #14

I work as a C++ developer, but damn, C++ has the ugliest lambda syntax ever.

Do you have an alternative suggestion? It seems reasonably straightforward to me and I don’t find it all that impossible. Not having to muck around with a specific lambda() factory-like function with horrible inputs (as is needed in LPC where I sort-of learnt to code) is a plus :)

I don't mind C++'s lambdas, but in some other languages they use "arrows", like

   square = (x) -> x * x
C++ won't want to give up the different kinds of capturing, though, so it's hard to see anything much better than what's available now.

In imaginary, never-to-be-implemented language daydreams I toy with the idea of using curly braces and implicit positional arguments to have lambdas look like

    square = { _1 * _1 }
and

    factorial = { (_1
and with explicit captures and arguments,

    partial_sort = [&lt_vec, &ge_vec, pivot](item){
        if (item
I suspect, though, those ideas are just horrible shortcuts to a Perl-like hell :-)

Re: C++14 lambda tutorial

#26

Post by claudius »

repsilat wrote: post #25
claudius wrote: post #22

Earlier quoted context omitted.

Do you have an alternative suggestion? It seems reasonably straightforward to me and I don’t find it all that impossible. Not having to muck around with a specific lambda() factory-like function with horrible inputs (as is needed in LPC where I sort-of learnt to code) is a plus :)

I don't mind C++'s lambdas, but in some other languages they use "arrows", like square = (x) -> x * x C++ won't want to give up the different kinds of capturing, though, so it's hard to see anything much better than what's available now. In imaginary, never-to-be-implemented language daydreams I toy with the idea of using curly braces and implicit positional arguments to have lambdas look like square = { _1 * _1 } an…

Hrm, I don’t quite like the arrows. C++ lambdas can contain arbitrary code and these arrows always remind me of “pure” functions (in a sense), or at least functions whose main purpose it is to map input arguments to output arguments.

For example, consider something like this relatively common block to do some complex operation on the elements of a vector using some (naive) threading (it might be nicer to first create some lambdas, push them into a queue and then spawn threads to work on that queue, but the syntax is essentially the same):

  for(std::size_t i(0); i != somevec.size(); ++i) {
    workers.push_back(std::thread([&somevec, i]() mutable { calc(somevec, i); }));
  }
That is, we want an anonymous lambda which captures some elements of its environment (by both reference and value, also it’s essentially a closure by now) and call some function on these elements. That lambda doesn’t have any return value and doesn’t take any input arguments. Sure one could throw in an extra lambda somewhere or put an arrow between mutable and {, but I have to admit I don’t see the value.

Re: C++14 lambda tutorial

#27

Post by archgrove »

repsilat wrote: post #25
claudius wrote: post #22

Earlier quoted context omitted.

Do you have an alternative suggestion? It seems reasonably straightforward to me and I don’t find it all that impossible. Not having to muck around with a specific lambda() factory-like function with horrible inputs (as is needed in LPC where I sort-of learnt to code) is a plus :)

I don't mind C++'s lambdas, but in some other languages they use "arrows", like square = (x) -> x * x C++ won't want to give up the different kinds of capturing, though, so it's hard to see anything much better than what's available now. In imaginary, never-to-be-implemented language daydreams I toy with the idea of using curly braces and implicit positional arguments to have lambdas look like square = { _1 * _1 } an…

You might like Apple's Swift:

    class Example {
        let ExtraMul = 5
    }

    let weakly = Example()
    let squareAndABit : Int -> Int = { [weak weakly] in $0 * $0 * weakly!.ExtraMul }
    squareAndABit(2) // 20
Positional lambda arguments, implicit returns for single expression arguments, capture lists if you want to alter the default capture mode. It's got really rather nice first class function support.

Re: C++14 lambda tutorial

#28

Post by danielweber »

ninkendo wrote: post #8
thelinked wrote: post #6

Earlier quoted context omitted.

An interesting example of C++ not being able to introduce new keywords is the co-opting of auto in C++11 from a storage class to type deduction.

But they had a decent justification: the auto keyword literally did nothing in C++. The only place it was valid, it was also the default.

IIRC they audited a bunch of projects to see if anyone was using auto somewhere besides test code explicitly for the auto-keyword, and found nothing.

Re: C++14 lambda tutorial

#29

Post by crazypyro »

leni536 wrote: post #19
crazypyro wrote: post #11

Earlier quoted context omitted.

Isn't that literally a core principal of Python? They enforce all kind of coding styles within the language, not the mention all the PEPs.

But PEPs are not enforced in the language level. Also there are cases where there could fit two simple expression in a lambda. Also the language still doesn't stop you from abusing lambdas, you can nest them. It could be stated in one of the PEPs that "no overly complicated lambdas" and that's it, there is no need for the language to enforce this.

PEPs are literally the language, in my opinion. It may not be enforced on an implementation level, but some have been. You can't mix spaces and tabs now. That seems like a style choice being enforced on every level.

Re: C++14 lambda tutorial

#30

Post by crazypyro »

leni536 wrote: post #19
crazypyro wrote: post #11

Earlier quoted context omitted.

Isn't that literally a core principal of Python? They enforce all kind of coding styles within the language, not the mention all the PEPs.

But PEPs are not enforced in the language level. Also there are cases where there could fit two simple expression in a lambda. Also the language still doesn't stop you from abusing lambdas, you can nest them. It could be stated in one of the PEPs that "no overly complicated lambdas" and that's it, there is no need for the language to enforce this.

PEPs are literally the language, in my opinion. It may not be enforced on an implementation level, but some have been. You can't mix spaces and tabs now. That seems like a style choice being enforced on every level.
Post reply on HN