6 ms·
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
by hsn915 5y ago
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.
- inetknght 5y ago> 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.
- jcelerier 5y agoI 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
- Quekid5 5y agoThat'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.
- inetknght 5y agoI'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.
- jhgb 5y ago> 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.
- netr0ute 5y agoLambda GC doesn't matter if they're just syntactic sugar for plain old functions, which is how it is with G++.
- rnvannatta 5y agoC++ 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.
- int_19h 5y agoAlthough 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.
- a_t48 5y agoBut 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.
- slavik81 5y agoIf 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.
- jhgb 5y ago> 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.