Hacker News Reader

Hacker News

Comment by hsn915 | Hacker News Reader

Parent Full thread

hsn915

The whole point of using C++ in 2018 is to have control over memory layout and CPU instructions emitted.

If you think lambdas with GC are a good idea then you would not use C++. You would maybe use Go.

> Compile times matter in extreme cases, but 3 seconds is not really something I would worry about.

I think a lot of people would be very happy if their projects compiled in mere 3 seconds.

View on HN

> The whole point of using C++ in 2018 is to have control over memory layout and CPU instructions emitted.

Memory layout, yes.

CPU instructions emitted? Not so much.

I really disagree, on some of my use cases I measured the difference between -O3 (sse2) and -O3 -march=native (avx2) to be 30-to-50-ish percent faster

That's as may be, but nowhere in your program does it say that it should use either sse2 or avx2, which was the parent poster's point. At least that's what I understood it to be.

Technically you could have different code paths and inline asm, but that's not really specified by the C++ standard either.

I've found that `-march=native` with _any_ optimization level will almost always result in faster code. However, that faster code isn't always backwards-compatible to older generation hardware. And, where it is backwards-compatible, it can actually be slower.

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

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.

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.

Reply on news.ycombinator.com