Live data from Hacker News

C++11 FAQ

stroustrup.com

81–90 of 121 posts

Re: C++11 FAQ

#81

Earlier quoted context omitted.

I started with C++ around '92, but you are right, C++ was already complex back then, but it was still manageable, you could, sort of, hold its larger picture entirely in your head and still had some elegance to it.

1992 was just the year MFC came out. I would go as far as saying that C++ of the early '90s was at its Nadir of inelegance. I'd go as far as saying that C++ frameworks of the early 90s were the absolute nadir of elegance. STL only started getting into compilers around '95, so we had no standard containers and dozens of different string implementations. The only part of the standard library widely available was iostre…

> I would go as far as saying that C++ of the early '90s was at its Nadir of inelegance.

Yup. '92 C++ was what gave Java such a boost. If we'd somehow started with '98 C++, or better still C++11, Java might never have picked up so much momentum.

Re: C++11 FAQ

#82

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, even if it might have been necessary.

I think the main pain with move semantics was that it had to be bolted on to the language later. Consider that factor, they did an amazing job with it.

Re: C++11 FAQ

#83
post #41

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…

Template metaprogramming is not something new, it's old, and indeed much of Modern C++ (e.g. constexpr) is made to replace the complicated TMP with simpler and just-as-powerful abstractions. Can you name another language that supports the many high-level abstractions that C++ supports (OOP, generic programming) while being just as fast? Only D and Rust come to mind, and they are neither as fast nor, crucially, as wel…

Modula-3. Bonus points are awarded to Modula-3 and Rust for safety.

Re: C++11 FAQ

#84

Earlier quoted context omitted.

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__.

AFAIK, _ isn't an operator in Java (http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#...). The language does allow _ to be used as a separator in numeric literals.

Is there a new operator in some upcoming version of the language specification?

Re: C++11 FAQ

#85
Interesting to see the love/hate. We are just starting a new blank slate code base and decided to go straight to C++17. We need expressivity early on, high performance later. And a model where someone can really get high performance on the core and still let people prototype / experiment down the road. It's pretty well supported by gcc & clang which are the compilers we care about.

I haven't really done much C++ programming in 20 years so approached it as a brand new language (to me) that I'd never used before. It's a big but powerful standard. I can't say I adore the syntax, but it's subject to path-dependent constraints that you just have to put up with.

I'm still looking for good references to style and practice that are appropriate to the latest C++. Books targeted at C++11 are pretty useful but it's too early to have more than the standard to help with 1y features.

Re: C++11 FAQ

#86

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…

Odd. I wonder why they didn't just use Boost uBLAS or similar.

Re: C++11 FAQ

#87
post #4

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…

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 ?

One of C++'s most glaring problems is that everybody only ever uses some subset of some version of the language, but you still need to know basically the entire massive, monstrous language because not everybody uses the same subset and you need to be prepared for anything. On top of that, you're lucky if your employer or potential recipient of contributions (e.g., FOSS project) or whatever has actually codified the subset they want to you to use: most of the time, you need to infer the allowable subset from the existing code.

Re: C++11 FAQ

#88
post #65

Earlier quoted context omitted.

"char ∗(∗(∗a[])())()" may have entertainment value in an obfuscated C contest, but it is otherwise useless. Using && in templates may be advanced C++, but it is both useful and mainstream. You're essentially saying, "don't worry, no one uses the new language features anyway". But that's not a convincing response to a complaint about the incredible complexity introduced by a particular new language feature.

>You're essentially saying, "don't worry, no one uses the new language features anyway". No, I'm not saying that. A lot of C++ programmers are application programmers who glue together Qt GUI with some code to read a TCPIP socket or file and write out some data. Many C++ programmers simply don't have the day-to-day need to write generic templates (libraries). Yes, it may be useful and mainstream to you but I don't th…

>When I studied it, the "&&" syntax and type deduction rules seem to be "irreducible complexity".

That may well be, given a particular set of constraints. But that is exactly the issue with C++ today. It's a conglomerate of powerful and diverse features, and so everything that gets added interacts in countless ways with everything that's already there. There's no orthogonality at all. Everything is both irreducibly and impossibly complex at the same time.

You're right that meta programming is inherently more complex than other issues. But it's not the only area where C++'s complexity is outgrowing our (or at least my) cognitive capacity if the goal is to write reasonably reliable code in a reasonably productive way.

Re: C++11 FAQ

#90
post #78
post #62

Earlier quoted context omitted.

The thing is that something like computing primes with template instantiations was always a little weird and came with problems around sensible build processes. The rules were...well...complicated, but not that complicated. You had ADL rules that were weird, but basically, you could view a lot of the template hackery as a weird thing that you could understand without too much trouble, but probably didn't need to. Tha…

> C++ has always been complex, but I defy anyone to read "Effective Modern C++" from cover to cover without clutching their pearls in horror. Actually, Effective Modern C++ was pretty awesome. A good guide through all the complexity.

Oh, the book is awesome. I mean the fact that such a book had to be written is a pretty rough statement about the language.
Post reply on HN