C++14 lambda tutorial | Hacker News Reader

C++14 lambda tutorial

solarianprogrammer.com

63 pointsAlexeyBrin29 comments

As someone currently learning C++ the biggest surprise was finding out about C++11/14. I'd assumed that the language hadn't changed for decades so it's great to see it still being updated.

Yes. C++ is in an active standard update process. Here is a short history of notable versions:

Year Version Year-Delta

1983; 1.0; 0

1989; 2.0; +6 years

1998; C++98; +9 years (first ISO standard)

2003; C++03; +5 years (minor update)

2011; C++11; +8 years (major update)

2014; C++14; +3 years (minor update)

The C++14 version was the first that arrived on schedule. The next major version is planned for 2017. The future looks quite promising for C++.

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

Not as ugly as having to create a new class, IMO.

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 < 2) ? 1 : _0(_1 - 1) }

and with explicit captures and arguments,

    partial_sort = [&lt_vec, &ge_vec, pivot](item){
        if (item < pivot) lt_vec.add(item)
        else ge_vec.add(item)
    }

I suspect, though, those ideas are just horrible shortcuts to a Perl-like hell :-)

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.

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.

""In imaginary, never-to-be-implemented language daydreams I toy..""

Your mockup code sure looks like Lua.

Much better than writing a functor, a class which overloads ().

I've never been a good at Templates. After reading this it seems that a lot of Template uses can be replaced with the generic lambdas using auto as the types going in.

Am I wrong or misunderstanding? I'm not saying completely but I feel like when I have used Templates I can now use this.

My understanding is that auto can serve some of the role of templates, but that has no particular tie to lambdas that I can see.

Templates are the C++ implementation of "generics". Their utility extends far beyond lambdas-as-callables. The entire STL library is built using the Template feature of C++. Templates are far more important than the ability to do "true" object-oriented programming using other features, in my opinion.

For a more concrete example that doesn't rely on the "authority" of an externally developed template library, consider that templates are also useful for static/compile-time polymorphism (see: Curiously Recurring Template Pattern).

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

Backwards compatability. Old valid code should remain valid. That includes code which calculates wavelengths.

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.

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 that's possible, but I would strangle anyone who actually did that. At that point, not only are you pointlessly redefining the language just so it can feel slightly more familiar to people who are more comfortable with Python and the like, but you also completely lose the ability to enclose variables in the square brackets to make a closure.

If you're going to write C++, then write C++. Don't redefine language constructs to fit the patterns of your other favourite language.

I think you can

  #define begin {
  #define end   }

too. I would not suggest it though.

That way lies http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/...

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.

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.

That also dramatically reduces the value of lambdas. Without that limitation then they work as anonymous blocks of any complexity.

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.

Reply on news.ycombinator.com