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…
C++11 FAQ
31–40 of 121 posts
Re: C++11 FAQ
#32I'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 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
#33Earlier 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…
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
#34Earlier 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-...
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
#35I'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?
Re: C++11 FAQ
#36Earlier 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.
Re: C++11 FAQ
#37Earlier 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.
Re: C++11 FAQ
#38I'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…
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
#39Earlier 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.
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
#40Earlier 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.
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.