41–50 of 112 posts
This is ridiculous. C++ lambdas (and std::function) don't replace iterators except for the most fervent disciples of the Church of Haskell. They replace single-function interfaces in cases where you would have had to put together a custom struct that did exactly the same thing as a lambda with capture but in about 15 more lines.
Earlier quoted context omitted.
Being a language geek with major in compiler design and systems programming, I tend to be a bit language lawyer. I seldom meet C developers that are able to distinguish between ANSI C and my compiler's C, that extrapolate from my compiler's C version Y, how the language should behave. Then they port the code to my compiler's C version Y + 1, or another compiler vendor, their code gets broken, blame the compiler, only…
So is your compiler ANSI C or not? c89 or c99?
Earlier quoted context omitted.
Unfortunately most teachers aren't like Kate Gregory, and I fully agree with her, they should stop teaching C -> C++. Already in 1994 it was obvious to me that it leads to bad unsafe code and worse, the mentality to micro-benchmark each code line.
There's pitfalls to everything. I find that a lot of people that only learned C++ end up writing nice-looking safe code that's very well organized but has awful memory usage and dubious performance characteristics. It's not that they're bad programmers or made poor algorithmic choices. It's that they've been indoctrinated with the fear of "premature optimization". Moreover, they don't really know any better if they d…
In all my years as developer, even back on Spectrum, MS-DOS and Amiga, I never bothered turning off bounds checking and it seldom mattered for the type of applications I was writing.
The very few times it mattered, I was writing big chunks of Assembly anyway.
Everyone thinks their applications have the same performance requirements as Microsoft, Apple, Google, Facebook, CERN, Wall Street, Sony ... have, but they don't.
It is like the native code version of going web scale on day 1, when everything that one has are a few pages to display.
It is fairly easy to implement and the compiler will inline the functor so there is no performance penalty. Any solution based on iterators that I can think of would be much more complicated and would probably not lead to as efficient code.
I'll admit that the "user interface" for iterators are much nicer than using functors. The former meshes well with c++:s for loop syntax while the syntax for lambda constructs is bad.
The paper seems to study the use of lambdas specifically as an alternative to iterators. I actually mostly still use iterators myself, rather than lambda-based alternatives, so I agree: they don't have a huge impact there.
But the headline is misleading. It should have had "when compared with iterators" added to the end.
Earlier quoted context omitted.
Basically anywhere where you would have used a callback in C code could probably benefit from a C++ lambda. It's easier to see what's going on, you don't litter your code with hundreds (or thousands) of tiny functions, and the compiler can easily inline everything. The fact that you can capture whatever you need makes it super easy to use inside a class if needed (eg; you need to access class members). It seems reall…
I'd much rather have a lot of smaller functions with single responsibilities, but then being middle management I worry about things I didn't when developing. I need the code to be SOLID, I need the time to market to be as small as possible and I need to be able to replace any developer with any developer on a moments notice. When students don't know lambdas you're costing me money by using them, because you made the…
However, C++ lambdas picked the most horrifically ugly syntax possible, and they switch between three subtly different semantics (copy, reference, move) depending on a single glyph. I feel bad for the people working on modern C++ - maintaining backwards compatibility is a huge constraint upon design space.
I'm not surprised that lambdas slow down people that aren't already experienced with them. Since I rarely program in C++, whenever I go back to it, I always have to spend a bit of time bashing my head against the horrific syntax.
Earlier quoted context omitted.
But there is a difference between using C in crazy ways, and using 20 features of a language in ways that make them interact. The more features a language has, the more I have to know just to read someone's code or be productive in a company - and the more chance someone doesn't know about potential harmful interactions and side effects.
> But there is a difference between using C in crazy ways Is signed arithmetic using C in crazy ways? Is shifting by an arbitrary value without checking to make sure that the number of bits is in the valid range of the type using C in crazy ways? Undefined behavior is everywhere in C.
Earlier quoted context omitted.
But there is a difference between using C in crazy ways, and using 20 features of a language in ways that make them interact. The more features a language has, the more I have to know just to read someone's code or be productive in a company - and the more chance someone doesn't know about potential harmful interactions and side effects.
> But there is a difference between using C in crazy ways Is signed arithmetic using C in crazy ways? Is shifting by an arbitrary value without checking to make sure that the number of bits is in the valid range of the type using C in crazy ways? Undefined behavior is everywhere in C.
Lambdas are an incredibly useful construct, and, once you master them, they do make a lot of programming tasks much easier. However, C++ lambdas picked the most horrifically ugly syntax possible, and they switch between three subtly different semantics (copy, reference, move) depending on a single glyph. I feel bad for the people working on modern C++ - maintaining backwards compatibility is a huge constraint upon de…
[foo=std::move(bar)]() {}