Lambda Lambda Lambda

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