Hacker News Reader

Comment by jhgb | Hacker News Reader

> If you think lambdas with GC are a good idea then you would not use C++

Lambdas with GC are an extremely good idea, because of the silently shared environments and what not. Whether C++ should have lambdas if it can't guarantee GC is a completely different thing. C++ doesn't have to include everything to be fashionable, after all.

View on HN

Some programming ideas might be "good ideas" in the abstract sense. But in the context of "I want to have control over memory layout and CPU instructions" they impose unavoidable costs. If lambdas must be accompanied by a GC, then they are a non-starter for someone who wants to use C++ in 2018.

In 2022, this applies just the same to someone who wants to use Zig or Odin.

If you want to be really high level and not worry about memory, you would not be using these languages to begin with.

I like the MOP in Common Lisp but I would never suggest that C++ should have a MOP, too. No language has to have everything.

Lambda GC doesn't matter if they're just syntactic sugar for plain old functions, which is how it is with G++.

C++ Lambdas are capturing, so they aren't plain old functions. They evaluate to closures: function + environment. In C++ the captured environment is explicitly written in the [] section of the lambda.

The issue that I think the top comment is alluding to is that lambdas cannot capture by reference and then return, due to that stack frame becoming invalidated, which is a fairly large limitation that prevents swaths of lambda heavy code from working.

I personally think that this is a fine tradeoff for what C++ is: there's still plenty of utility in lambdas for simple higher order functions like maps and filters.

Although this kind of code is also exactly where Rust shines because ownership is explicit throughout, so you can't just accidentally forget that you captured something byref.

But hold up - capturing a stack variable by reference in a lambda isn't defined behavior - it will be garbage later when you try to read from it.

If your lambda doesn't capture any variables, it can be converted to a function pointer.

You can also just capture by value, rather than by reference. If you really want, there's also reference counting with shared_ptr.

> You can also just capture by value, rather than by reference.

Those things are misnomers anyway. Having access to an enclosing environment via a free variable in a lambda expression is completely orthogonal to values vs. references. I suspect they should have named the whole thing differently.

A c++ lambda is a struct with a call operator. The destructors of captured objects are appropriately called when the lambda's lifetime ends.

Managing the lifetime of referenced objects is something you always have to worry about in c++ anyway, lambdas don't change that.

I feel like some people may be assuming that a capturing lambda must necessarily dynamically allocate memory, and that's just not always true.

The large majority of lambdas that I have written in c++ didn't need to do any dynamic allocation because they were used in (and only in) the scope where they were defined. Most of the time the compiler probably just inlined them.

Reply on news.ycombinator.com