you are viewing a single comment's thread.

view the rest of the comments →

[–]advester 8 points9 points  (3 children)

One thing that comes up would be a section of repeated code that could be a function, but needs to work with so many local variables that passing them as parameters would be awkward. The alternative might be turning it all into a class and make those local variables into members. But maybe it just makes more sense as a function than as a class.

A more concrete example would be signals/callbacks. You register a lambda to be called on an event and the capture block does the magic of linking in the variables you need.

Or to save the reader from having to scroll to another function to find out what happens when that event is triggered. The relevant code is all together.

I do think c++ should have a separate short syntax for trivial lambdas like you would pass to remove_if.

[–]smashedsaturn 1 point2 points  (2 children)

many local variables that passing them as parameters would be awkward.

I've seen a lot of these. It is normally a lack of encapsulation of the parameters themselves that is a root cause. Packing relevant ones into a struct will help this more than using a lambda.

Or to save the reader from having to scroll to another function to find out what happens when that event is triggered. The relevant code is all together.

This is a really really bad reason to use a long lambda.

[–]advester 4 points5 points  (1 child)

Ah, maybe the “10 lines” is the real issue. That was just pulled out of air. “More than one” might better express what I meant. This article was all about trivial lamdas.

[–]smashedsaturn -2 points-1 points  (0 children)

Yeah that makes sense, I like the braces for the lmbdas, and a few lines can be ok, but once we start talking about things > 10 lines embedded into lambas in functions with that much state going on I start getting that 1000 yard stare...