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

101–110 of 112 posts

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

#101

Post by eropple »

EGreg wrote: post #99
eropple wrote: post #94

Earlier quoted context omitted.

Who said anything about inheritance? Like, at all? That is yet another feature you pay for only when you adopt it. You can pick one of two problems: you can agree upon a subset of C++ to use or you can expect your C developers to be perfect all of the time (while having fewer, if any, ways to express correctness). Dragging out additional things that are not part of your subset of C++ doesn't help formulate an argumen…

I agree about C needing memory management and exceptions. That's why I said I liked C++ when that's all there was. Classes were nice sumyntactic sugar. But the language jumped the shark starting with C++0x

C++0x adds nothing you are obligated to use, though. No sharks have been jumped unless you choose to strap on some skis and rent a boat. (Meanwhile, with move semantics and unique_ptrs, C++14 is actually way nicer as far as memory management goes than that 2000-era C++ was.)

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

#102

Post by lcvella »

It seems that the most important conclusion of the article is that using lambdas is more error prone than using iterators. What begs the question: how many compiler errors were caused by the actual lambadas, and how many were caused by the declaration of a `std::function` variable, as induced by the authors (that besides unnecessary, is somewhat of a bad style)?

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

#103

Post by eropple »

pjmlp wrote: post #28
eropple wrote: post #14

Earlier quoted context omitted.

I think the profusion of use-after-free bugs and memory leaks in C code running all over the place should put the lie to this. And, further, modern C++ allows you to firewall off the damage of bad C++ and most C, when you are forced to interact with it, via unique_ptr and your own enforced RAII. (And the idea that using this is so pejoratively "shackling" is bonkers to me; being "shackled" to the use of railings on w…

And we already could take advantage of many of those positive features with C++ARM. Hence why I eventually did a Turbo Pascal -> C++ transition, with a very very short stop in C. I was lucky that our technical school also had access to Turbo C++ 1.0 for MS-DOS on their software library. As I was not getting why should I downgrade myself from Turbo Pascal 6.0 into C. Already in those days of "The C++ Report" and when…

This is a really interesting notion. I'd love to follow up with you offline. Drop me an email?

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

#104

Post by beagle3 »

EGreg wrote: post #98
eropple wrote: post #14

Earlier quoted context omitted.

I think the profusion of use-after-free bugs and memory leaks in C code running all over the place should put the lie to this. And, further, modern C++ allows you to firewall off the damage of bad C++ and most C, when you are forced to interact with it, via unique_ptr and your own enforced RAII. (And the idea that using this is so pejoratively "shackling" is bonkers to me; being "shackled" to the use of railings on w…

So that's easy: #define NEW(t, args...) ((t*)malloc(sizeof(t)) && t ## _construct(args)) #define DELETE(t) (t ## _destruct() && !free(t) && (t = NULL))

In DELETE(), is t the variable name or the type name? It is used as both, which won't work.

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

#106

Post by gpderetta »

swift wrote: post #95
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.

I'm not so sure. Generally implementing an iterator when the iteration doesn't represent a straightforward walk over the elements of a collection is much more error-prone. The implementation of the lambda version looks exactly the same as if you were just performing the iteration locally, while the iterator version requires saving and restoring a bunch of state and handling more edge cases. At call sites, the iterato…

Writing iterators is non trivial, but, lacking first class continuations, external iterators (a-la begin, end) are more powerful than internal iterators (a-la for_each), as they allow iterating multiple ranges at the same time and easily defining subranges.

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

#107

Post by gpderetta »

72deluxe wrote: post #62
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.

Yes, especially irritating in C++2003 here at work! you realise how useful the capture list is with lambdas when you have an in-function struct that can't see outside its own scope so you need to pass everything in (and won't have access to private portions of the outer class). Lambdas really are great.

> and won't have access to private portions of the outer class

Nested and member function local classes are actually implicitly friends of the containing class. Not all compilers were conforming in this area though.

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

#108

Post by alfalfasprout »

72deluxe wrote: post #64
alfalfasprout wrote: post #31

Earlier quoted context omitted.

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…

Out of interest, I never learned C but went straight to C++. What in particular about C++ makes you believe that you'll write memory hogging programs?

Specifically, the STL has a lot of slow containers that people readily use. For example, a beginner might see a std::map and think "wow, a handy hash table class!". First off, it's not a hash table (usually a RB tree). Second, the closest thing to a hash table in the STL (std::unordered_map) is still pretty slow.

Then there's std::string. Super nice in 95% of cases but can cripple an application if you have millions of strings you need to deal with (TONS of dynamic memory allocation).

And then there's std::shared_ptr. Super convenient but potentially a huge impact if you have items with very short durations in hot loops. std::unique_ptr on the other hand has no added overhead. Sure, you can look these things up. But it's not really obvious.

C++ is an incredibly useful language. It's far from the safest, prettiest, etc. But when used properly it's a very powerful tool. But knowing C can help you to better understand when you're not getting something for free and when undefined behavior can rear its ugly head.

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

#110

Post by 72deluxe »

delegate wrote: post #82
72deluxe wrote: post #67

Earlier quoted context omitted.

Yes C++ is complicated and yes students struggle with programming. It takes years to understand how to put a decent program together (separation of data, logic and transport etc). As for your guesswork with C-style strings, you should have been using std::string and using copy constructors to pass work into a thread (eg. who owns the data the thread is working on?). With modern things you can move the data into the t…

I started programming back in the day when every programmer wrote his own String class :). Standard library was, for one reason or another, unpopular back then. Or maybe because of the C Windows API and later MFC, which came with its own CString class...

Add to the confusion CString, BSTR and std::string and std::wstring. What could go wrong?
Post reply on HN