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

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

fluentcpp.com

Post reply on HN
Print view View original

71–75 of 75 posts

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

#71

Post by pjmlp »

MontagFTB wrote: post #43
MauranKilom wrote: post #37

Earlier quoted context omitted.

There is tooling along those lines. I wouldn't expect to find a tool that forbids non-auto declarations, but there are certainly some that suggest when something could've been auto.

Right. clang-tidy lets you specify rules you’d like it to enforce in the code you pass through it. It’s not a part of the compilation process, but uses the same underlying driver (if you’re building with clang)

On large projects it can be integrated into the build pipeline, so in a sense it becomes part of the product compilation process, even if not on the local workstation.

I am a big friend to push good coding practices into the CI/CD configuration, regardless of the programming language.

Anyone can do whatever they feel like on their own computer, but the overall product has guidelines to follow, specially relevant in projects that live from changing consulting companies all the time.

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

#72

Post by trhway »

MauranKilom wrote: post #33
vitus wrote: 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…

> templates should never be an answer to "my type is too long to type out" Eh, in some cases it's a wash. std::vector > objects; // ... auto it = std::find_if(objects.begin(), objects.end(), [](auto& widget) { return widget->x == 1; }); Sure, you could repeat the type `std::unique_ptr ` in the lambda, but that's just noise. You don't spell out the types like that either in, say, C#. Yes, compilation time is an epsilo…

auto is an evil temptation that we've gave ourselves easily in.

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

#73

Post by b20000 »

Kranar wrote: post #59
b20000 wrote: 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.

I interview a lot of C++ developers who have 20 or more years of experience I feel really bad when the vast majority of them fail to keep up with modern standards or take the time to understand their tools resulting in all kinds of misconceptions based on outdated information. Lambda expressions do not involve any kind of hidden allocations, their definition is precisely formalized and can be reviewed in S 7.5.5 of t…

Maybe the allocations I was referring to came from using std::function. My point was that if you are not careful when you write software in C++ and use modern features, you will get behaviour you don't want or didn't expect.

I have no time to read the standard or keep up with it. Maybe that is what people at Google can afford to do? I'm guessing that is where you work.

I run a small business, and I have to juggle a lot more than just writing code. When I have a problem, I figure out where it's coming from, and fix it. If you run your own business I'm sure you understand that.

Not keeping up with the standard has nothing to do with ignorance or refusal, but with constraints. I also don't think it should be required to know the standard, or the syntax for features you don't need to use everyday of the top of your head. If you are not sure, look it up. That's what the internet is for.

In any case, no need to be arrogant and dismiss people with experience as stupid or ignorant, or blaming them for spreading misinformation, simply because they don't know certain syntax by heart or don't keep up with the standard.

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

#74

Post by ncmncm »

pjmlp wrote: post #70
ncmncm wrote: post #64

Earlier quoted context omitted.

Both which ways? C was adopting C++ features before C90. Void type, function prototypes, scoped struct member tags. Declaration syntax is not an impediment to safety or to static analyzers, except insofar as it is trickier to code a parser for them.

It is in the sense that pointers everywhere cannot be prevented and it isn't always easy for a static analyser to actually make sense of how they are being used, as shown at some CppCon talks this year from Microsoft.

Declaration syntax has nothing to do with "pointers everywhere".

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

#75

Post by Kranar »

b20000 wrote: post #73
Kranar wrote: post #59

Earlier quoted context omitted.

I interview a lot of C++ developers who have 20 or more years of experience I feel really bad when the vast majority of them fail to keep up with modern standards or take the time to understand their tools resulting in all kinds of misconceptions based on outdated information. Lambda expressions do not involve any kind of hidden allocations, their definition is precisely formalized and can be reviewed in S 7.5.5 of t…

Maybe the allocations I was referring to came from using std::function. My point was that if you are not careful when you write software in C++ and use modern features, you will get behaviour you don't want or didn't expect. I have no time to read the standard or keep up with it. Maybe that is what people at Google can afford to do? I'm guessing that is where you work. I run a small business, and I have to juggle a l…

>My point was that if you are not careful when you write software in C++ and use modern features, you will get behaviour you don't want or didn't expect.

This is an unsubstantiated point and simply untrue. Modern features have worked hard to maintain what is referred to as "zero cost abstractions".

>If you run your own business I'm sure you understand that.

I do own and operate a business, a quant firm engaged in HFT. It's part of the reason why I hire so many C++ developers.

>Not keeping up with the standard has nothing to do with ignorance or refusal, but with constraints.

The ignorance comes from going into an interview where one would presumably be expected to have a basic understand of modern C++ functionality and then proceeding to call that interview BS when in fact it was you who simply had a poor understanding of what was expected.

If you don't want to use lambda expressions or you feel like using C++ like it's still the year 2003, so be it, that is your choice... just don't be surprised and go around calling interviewers full of BS when you continuously refuse to keep your understanding of technology up to date.

The problem in this case is not with the "BS interview" or the interviewer, the problem is with you. If you do not keep your understanding of C++ up to date, for whatever reason, then an interviewer is right to reject you for it in favor of someone who does take the time to keep their skills up-to-date.

Post reply on HN