Live data from Hacker News

The Evolutions of Lambdas in C++14, C++17 and C++20

fluentcpp.com

21–30 of 75 posts

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#21
post #13
post #7

Earlier quoted context omitted.

That is what happens when a language makes the compromise to be copy-paste compatible with https://cdecl.org/

More to the point, it means the language continues to interpret header files from C libraries the same way that the C compiler always has.

It goes both ways, back in CFront days, and when it was picking up steam across MS-DOS, Mac OS, UNIX, among others.

Unfortunely it is also an hindrance to fix some issues that prevent C++ to ever embrace safety, or better implementation of static analysers.

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#22

Earlier quoted context omitted.

I think grandparent is referring to myLambda - that could be a new variable or overwriting of an existing one. I agree with them, in Python the number of times something like this happens: myVariable = 10 myVariablr = clever_function(myVariable) (note the typo in variable name)

>> in Python the number of times something like this happens Anec-data but I’ve been writing python for 15+ years, I’ve contributed to various popular open source projects. I’ve never seen this in a code review. I’ve certainly never seen this kind of mistake released.

I've seen a variation of this bug several times in just the last year:

    myVariable = 1
    if not something_unusual():
        myVariablr = 2
    return myVariablr
This code will work just fine until something_unusual() returns True and then it crashes with UnboundLocalError: local variable 'myVariablr' referenced before assignment

This really sucks when it happens during a long-running job. Say for example you're looping through an array in chunks and distributing each chunk across GPUs. The last chunk will have fewer elements than all the others, maybe even 1 element. If you don't pad the chunk, it will go through a different (and likely underutilized) code path downstream and crash like this.

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#23
> Even if you don’t need to handle several types, this can be useful to avoid repetition and make the code more compact and readable.

...

> namespace1::namespace2::namespace3::ACertainTypeOfWidget

Deeply nested namespaces are problematic in themselves due to namespace resolution (e.g. see https://abseil.io/tips/130), but templates should never be an answer to "my type is too long to type out". You're hurting yourself at compile-time, and your code is now more error-prone as you can pass in any argument.

Just add a using-decl (or a namespace alias if the base name isn't meaningful enough for you).

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#24
post #17

Earlier quoted context omitted.

Problems with std::function:- 1. It can not hold move only callable objects. 2. It heap allocate stored callable object if the object is large enough.

3. Type-erased (its primary use case, but hinders optimization) 4. Can't be constexpr

Also, std::functions are not comparable. This makes it harder to use for registration/de-registration or an Observer architecture.

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#25
i was in a leetcode BS interview a while ago with a googler who thought i could not write code in c++ because i could not remember lambda syntax. i only use maybe 30% of c++ features in my software and have been doing this for over 20 years. it’s only recently i started using lambdas more, but still stay away from them because of the potential hidden allocations.

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#26
post #2

C++23 drop the word auto? myLambda = [](&&x){ std::cout what's the point of having to write auto everywhere

syntactical disambiguation, there's already something called "the most vexing parse". C++ is full of little holes like these and getting rid of auto would surely at least double compile times or at worst make parsing C++ actually impossible.

Yes, those things creep up in various places. Some are fixed, like when you have std::vector> where it used to give an error because it thought >> was an operator. But recently I discovered this one:

    int x[100] = {}; // just a regular array
    int val = x[[]{return 42;}()]; // compile error!
Once again, greedy parsing is the culprit; here it thinks [[ is the start of an attribute.

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#27
post #23

> Even if you don’t need to handle several types, this can be useful to avoid repetition and make the code more compact and readable. ... > namespace1::namespace2::namespace3::ACertainTypeOfWidget Deeply nested namespaces are problematic in themselves due to namespace resolution (e.g. see https://abseil.io/tips/130 ), but templates should never be an answer to "my type is too long to type out". You're hurting yoursel…

Yes, deeply nested namespaces are not nice. I think boost really dropped the ball on this. boost::asio::ip::tcp should have been boost::tcp. Are they trying to be as bad as java?

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#28
post #22

Earlier quoted context omitted.

>> in Python the number of times something like this happens Anec-data but I’ve been writing python for 15+ years, I’ve contributed to various popular open source projects. I’ve never seen this in a code review. I’ve certainly never seen this kind of mistake released.

I've seen a variation of this bug several times in just the last year: myVariable = 1 if not something_unusual(): myVariablr = 2 return myVariablr This code will work just fine until something_unusual() returns True and then it crashes with UnboundLocalError: local variable 'myVariablr' referenced before assignment This really sucks when it happens during a long-running job. Say for example you're looping through an…

Dynamic languages often benefit from some tool assistance. Both your and GPs experience can happen at the same time: GP is probably using a linter or an IDE (like Pycharm) which will point out that "myVariablr" may be undefined.

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#30
post #25

i was in a leetcode BS interview a while ago with a googler who thought i could not write code in c++ because i could not remember lambda syntax. i only use maybe 30% of c++ features in my software and have been doing this for over 20 years. it’s only recently i started using lambdas more, but still stay away from them because of the potential hidden allocations.

What kind of hidden allocations?
Post reply on HN