Live data from Hacker News

C++11 FAQ

stroustrup.com

31–40 of 121 posts

Re: C++11 FAQ

#31

I've been programming for money for over 20 years and I grew up professionally writing C and then half-migrating to C++, because the latter very naturally captured lots of C patterns and allowed for more succinct expression of the same. It was lean, expressive and elegant . Just needed a bit of Lisp-y closures and it would've been perfect. And then things got completely out of hand. Elegance was nuked from the high o…

But C++ was never easy to understand. For example, can you tell me off the top of your head, what are the conditions to get the compiler to generate a copy constructor and an assignment operator for a class? I have trouble answering that question even with the help of Google, and you're talking pre-Google times.

Re: C++11 FAQ

#32

I've been programming for money for over 20 years and I grew up professionally writing C and then half-migrating to C++, because the latter very naturally captured lots of C patterns and allowed for more succinct expression of the same. It was lean, expressive and elegant . Just needed a bit of Lisp-y closures and it would've been perfect. And then things got completely out of hand. Elegance was nuked from the high o…

> move semantics Move semantics have been great, in my experience (enabling things like unique_ptr). What is causing issues here?

My personal main problem is things like you can't template on an r-value reference, as T&& in a template matches both r-value and l-value references and then you need std::forward or std::move and then I start getting confused.

I wish in templates they had gone with the suggestion I saw to use T&&& to mean "r-value or l-value reference", and then let T&& just mean "r-value reference".

Re: C++11 FAQ

#33

Earlier quoted context omitted.

This is perhaps one of the more unexpected opinions on C++ I've encountered. When I picked up C++ with Turbo C++ 3.0 in the early '90s, it was already widely regarded as an over-complex behemoth. Donald Knuth said of it in 1993, "Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said 'OK, we'll do them both'. So the language is too baroque for my taste." The la…

Arguably the std::move stuff and the semantics around it have added uncomfortable complexity to the language, even if it might have been necessary. Other than that I think other advances in C++11 and beyond have made for a quite nicer language to work in. I love C++11 and use it every day, but I think putting references in the language was an 'original sin'. They should have stuck with C's model: it's either a value…

> Arguably the std::move stuff and the semantics around it have added uncomfortable complexity to the language

Compared to using std::auto?

Nah man. std::move is far easier to understand than trying to shove both concepts down operator=. std::unique is simply easier to use than std::auto by any real measurement.

Re: C++11 FAQ

#34

Earlier quoted context omitted.

> move semantics Move semantics have been great, in my experience (enabling things like unique_ptr). What is causing issues here?

Move semantics are very useful, but there's also something wrong if articles like this are necessary or even possible: https://isocpp.org/blog/2012/11/universal-references-in-c11-...

Scott Meyer's articles (and numerous video presentations) on Universal References are educational but he doesn't make it clear to the audiences the bigger picture of where and why they'd need to really learn it.

The Forwarding Reference (aka Universal Reference) is for programmers writing generic templates. A lot of C++ programmers can do a ton of productive work and get by for years without writing any templates from scratch. Yes, they use others' templates (such as STL/Boost libraries) but they don't necessarily write their own. I have no survey data but I'll take a wild guess that less than 1% of C++ programmers need to memorize template Forward References.

As an analogy using the plain C Language, it's as if someone created very prominent blogs about the complexity of "char ∗(∗(∗a[])())()" with long paragraphs explaining how it's "an array of pointers to functions returning pointer to function returning pointer to char".

If that type of essay had a lot of visibility, people might think that "Wow the C Language is difficult and too complicated!" In reality, a lot of C programmers don't write complex declarations like that. The more common pointer-to-function for something like qsort() is very easy to write.

Re: C++11 FAQ

#35

I've been programming for money for over 20 years and I grew up professionally writing C and then half-migrating to C++, because the latter very naturally captured lots of C patterns and allowed for more succinct expression of the same. It was lean, expressive and elegant . Just needed a bit of Lisp-y closures and it would've been perfect. And then things got completely out of hand. Elegance was nuked from the high o…

> move semantics Move semantics have been great, in my experience (enabling things like unique_ptr). What is causing issues here?

I'm having trouble understanding the differences between a * and a &, and now with move semantics we have stuff like &&, && &, and && &&. Please stop!

Re: C++11 FAQ

#36

Earlier quoted context omitted.

Arguably the std::move stuff and the semantics around it have added uncomfortable complexity to the language, even if it might have been necessary. Other than that I think other advances in C++11 and beyond have made for a quite nicer language to work in. I love C++11 and use it every day, but I think putting references in the language was an 'original sin'. They should have stuck with C's model: it's either a value…

Surely references have intrinsic value to the programmer? They're a pointer that can't be moved or rebased. Other languages have only references, and in C++ you can use that convention and not have any extra confusion.

Except that references still can be bad: invalidated later on by an object deletion, no matter how many rules were enforced to assign the reference to begin with. And in an almost-worse sense, "sometimes" references can prevent this and sometimes not. Just not good enough, while syntactically making it harder to tell that references are being used in function calls and such.

Re: C++11 FAQ

#37

Earlier quoted context omitted.

Arguably the std::move stuff and the semantics around it have added uncomfortable complexity to the language, even if it might have been necessary. Other than that I think other advances in C++11 and beyond have made for a quite nicer language to work in. I love C++11 and use it every day, but I think putting references in the language was an 'original sin'. They should have stuck with C's model: it's either a value…

> Arguably the std::move stuff and the semantics around it have added uncomfortable complexity to the language Compared to using std::auto? Nah man. std::move is far easier to understand than trying to shove both concepts down operator=. std::unique is simply easier to use than std::auto by any real measurement.

My perhaps naive uneducated opinion: they should have added syntactic sugar for it instead of making it look like a function. A new operator perhaps.

Re: C++11 FAQ

#38

I've been programming for money for over 20 years and I grew up professionally writing C and then half-migrating to C++, because the latter very naturally captured lots of C patterns and allowed for more succinct expression of the same. It was lean, expressive and elegant . Just needed a bit of Lisp-y closures and it would've been perfect. And then things got completely out of hand. Elegance was nuked from the high o…

I agree. The other day I had to dive into the libigl [1] matrix structure (for those that don't know, a matrix is basically a 4x4 grid of numbers). What I found was over 10 levels of inheritance, along with rampant template use and macros _everywhere_. It actually took so long to parse I ended up just changing my algorithm completely to avoid having to use it. I have utmost respect for anyone that can work with C++ d…

The problem is that you can find bad code in any language. It's difficult to tell how much that is the fault of the language, and how much is the fault of that particular author.

I'm not defending C++ here, I actually agree with you, but it's difficult to provide decent evidence for its failings.

Re: C++11 FAQ

#39

Earlier quoted context omitted.

> Arguably the std::move stuff and the semantics around it have added uncomfortable complexity to the language Compared to using std::auto? Nah man. std::move is far easier to understand than trying to shove both concepts down operator=. std::unique is simply easier to use than std::auto by any real measurement.

My perhaps naive uneducated opinion: they should have added syntactic sugar for it instead of making it look like a function. A new operator perhaps.

> A new operator perhaps.

That'd invalidate a lot of programs. Just like how the new _ operator in Java is killing a lot of code right now.

Every symbol that can be used... has been used. "Move" is the meaning of the operator in any case. Its no less readable than say... Python's __lshift__ or __add__.

Re: C++11 FAQ

#40
post #4

Earlier quoted context omitted.

some of the pain points you refer to, esp move semantics, bring a lot of additional performance to the table. Would you feel the same way about C++ if you started now and only had to learn a clean C++11 subset going forward ?

I've often wondered how anybody manages to teach C++ today. I love working with the language, and I understand the reason behind many of the features, but I can't help but feel like it would be impossible to teach to beginners.

Here is the course I was taught by at university:

http://www.dcs.bbk.ac.uk/~roger/cpp/

Lots of value came from the lectures with roger. Sadly he has retired, it would have been nice to have them up on youtube.

Post reply on HN