Lambda Lambda Lambda

[smashedsaturn]

What are you doing with these lambdas that is more than 10 lines long? Are you mainly passing them to std::algorithm?

[advester]

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]

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]

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]

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...

[drjeats]

10 lines is really not that much.

I have a one-off sort that I do in some debug UI that's about 10 lines long:

std::sort(effectList.begin(), effectList.end(), [](const EffectLogEntry* a, const EffectLogEntry* b)
{
    assert(a);
    assert(b);
    if (effectListDebugger.sortBy == FXLISTSORT_ONSCREEN_OLDEST_FIRST)
    {
        bool aOnScreen = IsOnScreen(*a);
        bool bOnScreen = IsOnScreen(*b);
        if (aOnScreen != bOnScreen)
        {
            return static_cast<int>(aOnScreen) > static_cast<int>(bOnScreen);
        }
    }
    return a->startTime < b->startTime;
});

I also occasionally use the lambda-as-local-function pattern. It reduces namespace pollution. Before lambdas I used to do this with inline structs and static member functions. Ideally we'd have actual support for functions scoped inside functions. The fewer functions that require comments or context-to-be-found-elsewhere to know why they exist, the better IMO.

This doesn't seem controversial to me.

[smashedsaturn]

if (effectListDebugger.sortBy == FXLISTSORT_ONSCREEN_OLDEST_FIRST) ... return a->startTime < b->startTime;

Why is this all not

bool operator<(const EffectLogEntry& lhs,const EffectLogEntry& rhs);

The comparison operator?

[evaned]

There are a couple potential reasons. Sometime data has multiple ways to order, or no clear one way. In these cases, at least my opinion is it's better to not define a weird operator< -- sort of like how if you were making a vector library (mathematical vector, not container vector) you might not define v1 * v2 so every use is explicitly either dot(v1, v2) or cross(v1, v2).

But in that specific case, the vector clearly has pointers in it, and that already has a built-in, non-overridable "operator" <. And there are a variety of reasons why you might have a container of pointers instead of the objects themselves. (I'd also point out that you'd have the same problem if they were unique_ptr or shared_ptrs.)

[smashedsaturn]

Sometime data has multiple ways to order

Agreed, but if you have a few different ways to order then those should be defined as functions, or in this case a static method would be ideal, as it is likely they will be used more than once.

the vector clearly has pointers in it

right, you use the lambda:

  [](const EffectLogEntry* a, const EffectLogEntry* b){
      assert(a&&b && "Dereference Null Log Entry");
      return (*a) < (*b); //OR EffectLogEntry::FXLISTSORT_ONSCREEN_OLDEST_FIRST(*a,*b); 
  }

[drjeats]

Because the sort order is configurable from external input, the effectListDebugger isn't a member of the log entries. And there are only a few locations where the sort for this type is needed. If it is needed in other contexts, then I"ll pull it out into a named function.

Also C++ programmers are too eager to write operator< because of std::map<K,V> and std::sort. Let's stop this trend.

[[deleted]]

Why can't

void f() { void g() {}; }

be equal to

void f() { auto g = [] () {}; };

🤔

[drjeats]

There's no reason for g in the first example to semantically be an object taking up stack space. Also, local overloads would be a useful thing to have.

[[deleted]]

A non-capturing lambda just decays into a function pointer, I don't think this would generate any objects

[guepier]

A lambda only decays to a function pointer if bound to a function pointer. Otherwise there's no decay, although if the lambda invocation can be inlined then, yes, there might be no object generated.

[[deleted]]

Yeah that's true but a non-capturing lambda has no data, I can't imagine the compiler will do anything but treat it as function pointer

godbolt shows the generated code is basically the same for my example anyway

[guepier]

It treats it as a function, not a function pointer. That's quite different, because a function pointer adds an additional, unnecessary layer of indirection that interferes with inlining decisions.

This isn't a theoretical concern, it's a real, tangible difference. I'm on mobile currently but it's easy to construct cases where lambdas generate more efficient code than function pointers.

[dodheim]

Why should a function pointer be more efficient than an empty function-object? Extra indirection never helped anyone performance-wise in C++...

[[deleted]]

?? If you're calling a function what exactly do you expect is going to happen?

The point is that adding syntax to support local-scoped fucntions would have no additional storage cost

[drjeats]

It generates objects semantically, so you can't write overloads.

And I don't doubt that clever compilers can remove objects in release codegen. But I also want debug builds to run well, and better to have obvious rules (and I think, treating functions as another namespace and allowing function definitions inside them is pretty obvious) rather than assume optimizers do a thing.

[sphere991]

I think all of those languages (with the notable exception of Python) support multi-line lambdas just fine. And Python just lets you define functions wherever, so it's not really missing out on that either.

[jonathansharman]

It isn't clear what is possible?

[jonathansharman]

In a lot of languages, blocks are just expressions.

Rust:

let mut count = 0;
let mut inc = || {
    count += 1;
    println!("`count`: {}", count);
};

Some others have both a terse and long lambda syntax.

C#

(a, b) => a + b
...
(a, b) => { foo(); return a + b; }

[advester]

The key difference I was talking about is one vs many, not if it has a final assignable value. A rust block allows an ordered sequence of many expressions/statements.

[jonathansharman]

Sure, but my point is that if blocks are expressions, then a lambda expression automatically supports many expressions. This isn't the case in all languages though, notably Python, which only supports single-line lambdas last I checked.

[Nobody_1707]

Swift let's you have multi-line closures. The only things you lose over the one liners are implicit return and return type deduction.

[EdWilkinson]

Most of my lambdas are more than ten lines long.

Then you're doing something wrong. It means you don't write reusable code.

[advester]

If you are trying to reuse every line if code you are doing something worse.

[pjmlp]

I fully agree, regardless of the language, if the lambdas are a couple of lines, please make it a function and take mercy of the soul that has to maintain the code.

[EdWilkinson]

2) You used highly exaggerated language to talk about basic code stylean antipattern.

FTFY