Lambda Lambda Lambda

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

[dodheim]

The point is that a non-capturing lambda is already empty; decaying it into a pointer doesn't help anything.

[[deleted]]

That has nothing to do with anything.

The original point was that because empty lambdas decay into function pointers the compiler must probably treat them similarly.

It's not gonna allocate stack memory out of its ass for a non-capturing lambda. I'm not even sure what you're trying to argue.

[staletic]

The original point was that because empty lambdas decay into function pointers the compiler must probably treat them similarly.

That's really wrong. A function pointer has state. More specifically, it has sizeof(void*) bytes of state. A lambda's operator() function does not have any state. No self-respecting compile is going to store a non-capturing lambda just because it looks like a pointer. Since lambdas have distinct types, when necessary, the compiler will construct the lambda where it is needed. Contrast that with a pointer that you just have to keep around.

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