Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An empirical study on the impact of C++ lambdas and programmer experience

dl.acm.org

Post reply on HN
Print view View original

51–60 of 112 posts

Re: An empirical study on the impact of C++ lambdas and programmer experience

#51

Post by nly »

ThePhysicist wrote: post #36

Recently I wrote a parser generator, which would take a rule structure and return a function that does the parsing. Lambdas were very useful here, and I do not know how I would've implemented this without them, at least in an efficient manner, because they let me do something like this: Parser ParserGenerator::compileLiteral(Rule& rule){ const string literal = rule.value; Parser parser = [literal] (shared_ptr state){…

Well, an alternative approach might to not to couple parsing and state manipulation :)

PEGTL does this. Approximately, you have a template parameter MyAction on the Parser template which in turn calls "MyAction::apply (state)" when parsing of each rule is complete.

It's a fantastic library. I highly recommend giving it a whirl.

[0] https://github.com/ColinH/PEGTL/blob/master/doc/Actions-and-...

Re: An empirical study on the impact of C++ lambdas and programmer experience

#52

Post by rubber_duck »

emcq wrote: post #7

The paper seems to mainly compare iterators vs lambdas. This seems like a bit of a strawman; the best use of lambdas is beyond iterators. For example, consider callback heavy asynchronous code. A promise library with lambdas is much easier to write and read than the equivalent state machine. I would go as far to say any mechanism where function chaining is useful, such as the nice data to mark/SVG abstraction used in…

>A promise library with lambdas is much easier to write and read than the equivalent state machine.

async/await makes this even easier, AFAIK C++ is getting it soon as well.

Re: An empirical study on the impact of C++ lambdas and programmer experience

#53

Post by duneroadrunner »

MaulingMonkey wrote: post #13
porges wrote: post #3

> After instructions, participants were given printouts of sample code they could refer to while solving tasks. Group Lambda got code of a C++ program using lambda expressions and group Iterator received code of the same program written using iterators. They then had time to study the samples before starting the tasks and could refer to these samples later. These samples do not appear in the paper, so we don't know w…

Yeah - from what I can see, neither interface looks like idiomatic C++. EDIT: Looks like you beat me to the punch on some of these ;) Instead of: float getSum(marketBasket mb) { float retVal = 0; // Implement solution here // --------- marketBasket::iterator iter = mb.begin(); while (iter.hasNext()) { retVal += iter.get().price; iter.next(); } // --------- return retVal; } I'd rather see real SC++L compatible iterato…

"Idiomatic" doesn't necessarily mean better. I think objectively it's hard to argue that "item != market.end()" is superior to "iter.hasNext()". The latter accurately reflects the programmer's intent, while the former specifies an unnecessarily specific (and poor) implementation of the intent. First of all, using something like "market.cend() != const_iter" instead is arguably better practice (imagine you unintentionally omit the "!"). But programmers shouldn't need to consider whether the iterator is const or not when they just want to know if the loop is done. Also, consider the case where the vector is being modified (items inserted or deleted) inside the loop. It might be problematic either way, but "item != market.end()" is particularly bad in that situation.

Shameless plug: http://duneroadrunner.github.io/SaferCPlusPlus/#msevector

Re: An empirical study on the impact of C++ lambdas and programmer experience

#55

Post by mickronome »

eksemplar wrote: post #40
alfalfasprout wrote: post #24

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…

If you want solid code in C++ you (essentially) have to only hire people who are good at their job, or accept a long runway where lambdas would simply be taught instead of the inferior methods/patterns they are intended to replace.

I have yet to see a C++ codebase which was good while not written by people who are essentially C++ experts, or through in-depth code reviews by such, for all code. I understand finding the talent may be hard, but then the C++ volume might need to be decreased and replaced by something less demanding, or the code will likely be anything but solid.

Re: An empirical study on the impact of C++ lambdas and programmer experience

#56

Post by lorenzhs »

duneroadrunner wrote: post #53
MaulingMonkey wrote: post #13

Earlier quoted context omitted.

Yeah - from what I can see, neither interface looks like idiomatic C++. EDIT: Looks like you beat me to the punch on some of these ;) Instead of: float getSum(marketBasket mb) { float retVal = 0; // Implement solution here // --------- marketBasket::iterator iter = mb.begin(); while (iter.hasNext()) { retVal += iter.get().price; iter.next(); } // --------- return retVal; } I'd rather see real SC++L compatible iterato…

"Idiomatic" doesn't necessarily mean better. I think objectively it's hard to argue that "item != market.end()" is superior to "iter.hasNext()". The latter accurately reflects the programmer's intent, while the former specifies an unnecessarily specific (and poor) implementation of the intent. First of all, using something like "market.cend() != const_iter" instead is arguably better practice (imagine you unintention…

> But programmers shouldn't need to consider whether the iterator is const or not when they just want to know if the loop is done.

and they don't: http://en.cppreference.com/w/cpp/container/vector/end - there's an overload returning a const_iterator. You don't need to use 'cend'.

And since insertion and deletion potentially invalidate iterators, 'hasNext()' is just as bad.

Re: An empirical study on the impact of C++ lambdas and programmer experience

#57

Post by byuu »

spacelizard wrote: post #18
byuu wrote: post #2

Context always matters. I use lambdas sparingly in my applications, except for one major area: user interfaces. I can't begin to stress what a huge timesaver it is being able to bind a button's callback to a quick lambda instead of having to bind a callback to an std::function, add the function to the class header, and then put the actual button-click code somewhere else in the project in a separate function ... and…

Yeah I think this is the real win - the examples in the paper don't really cover any of the real reasons why someone would use functional programming. The places that I've used C++ lambdas a lot are callback-heavy code, i.e. things with a lot of asynchronous I/O, multi-threading, etc. While I don't doubt the validity of the argument that it takes longer for a programmer to write correct lambda code in C++ (I have bee…

> It's also unfortunate to note that, at least in g++ and clang, there is still significant advantage to using lambdas over std::function and std::bind.

I have to say, std::bind is just a travesty. It's so difficult to bind a member function pointer that takes multiple arguments to an std::function.

I wrote my own so that you can do this with just: function f = {&Class::func, &object};

Source is here: http://hastebin.com/raw/kobudabasa

In doing so, it becomes clear there's basically two ways to implement this idea:

1. you allocate heap space to perform type erasure. This results in a pointer indirection plus a virtual function call worth of added overhead. Along with tremendous costs to allocate and destroy the function objects.

2. you store a big chunk of raw memory inside the function class, and cast it as necessary to a pointer. This is actually what I did prior to C++11 and lambdas. It was tricky because the size of member function pointers is undefined. Having a vtable makes them larger. So for that I made a complex dummy class to pull its sizeof info.

Option 2 is definitely a good bit faster (at least for constructing/copying/reassigning/destructing them), but you're really butting up against undefined behavior and abusing the language. And capturing lambdas would be even more challenging.

But even with that, yeah, you can't ever really beat concepts that are native to the language like lambdas and virtual functions themselves. Compilers can get really clever and inline things in a way that's exceedingly unlikely to ever occur with std::function, no matter how you implement it.

Re: An empirical study on the impact of C++ lambdas and programmer experience

#58

Post by hellofunk »

eksemplar wrote: post #40
alfalfasprout wrote: post #24

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…

This is a rather shallow perspective on software engineering. You are basically saying you don't want your employees to use the language as it is designed, even when it provides tools to make code better.

Re: An empirical study on the impact of C++ lambdas and programmer experience

#59

Post by lisardo »

GeneralMayhem wrote: post #27

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.

Ask them https://www.facebook.com/haskell.first.united.methodist.chur...

Re: An empirical study on the impact of C++ lambdas and programmer experience

#60

Post by gpderetta »

badminton1 wrote: post #37

Some people feel comfortable expressing things in a more traditional way, in part, because you cannot change the habits built over the course of decades by just announcing a new standard. After the standard including lambdas came out, compilers did not immediately comply to it, and it took some time for them to catch up. Then it took even more time for tutorials and books to catch up. And it will take time for the C+…

Compilers (at least clang, MSVC and GCC) released versions supporting lambdas well before the C++11 standard was finalized.
Post reply on HN