Live data from Hacker News

C++11 FAQ

stroustrup.com

61–70 of 121 posts

Re: C++11 FAQ

#61
post #34

Earlier quoted context omitted.

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 fr…

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

Re: C++11 FAQ

#62

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…

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…

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. That's much less true with most of the C++-11/14/17 features.

C++ has always been complex, but I defy anyone to read "Effective Modern C++" from cover to cover without clutching their pearls in horror.

Don't get me wrong, I actually like C++ in a weird way. There's nothing else out there that goes quite so far in putting you the programmer in charge while still attempting to let you work at a slightly higher level. But the price in cognitive load for this flexibility is just stupidly high.

Re: C++11 FAQ

#63

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…

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 iostreams, which is easily the most despised part of that library.

With no useful standard library to speak of, C++ devs were basically using the C standard library, rife with such shining gems of perfection as scanf(), strcat() and dear_hacker_please_inject_shellcode_here(). Since no generic containers were in sight, pretty much all 90s code I've had the pleasure to see was infested with macros. Pieces of exquisite beauty. I still have nightmares sometimes.

Then came the late 90s and early 2000s. The STL was widely supported, Boost started to gain ground and Andrei Alexandrescu released Modern C++ Design. Template metaprogramming slowly got out of hand and both code and errors were indecipherable.

The thing is, C++11 and beyond is the very opposite of this. Hairy template metaprogramming is replaced by simple and straightforward constexprs. Proper lambdas obsoleted functors, a gang of bloated design patterns (Visitor, Obeserver, Strategy, Command, Template Method, Decorator and so on) and several complicated lambda libraries from Boost.

Modern C++ is still a mess, but I believe it's way more elegant than ever before.

Re: C++11 FAQ

#64

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++ occupies the same mental space that languages like Haskell, Scala or OCaml.

Compared to its real competition, C++ is very elegant and a joy to use. These languages are meant for enjoying the maximum out of compile-time type abstractions, not as an easy-to-use tool for simple enterprise apps.

Re: C++11 FAQ

#65
post #34

Earlier quoted context omitted.

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 fr…

"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 think that is reflective of the whole C++ programming community at large.

>But that's not a convincing response to a complaint about the incredible complexity introduced by a particular new language feature.

When I studied it, the "&&" syntax and type deduction rules seem to be "irreducible complexity". Every computer science problem that involves one set of syntax to write another syntax (meta template programming) is complicated. This includes XSLT to rewrite XML, or PHP code that dynamically writes javascript syntax embedded inside of HTML syntax. Reading any of that code-that-writes-code is always ugly. If we were to challenge a language designer to recreate a syntax that meets the same exact goals of C++ (perfectly pass parameters without casts, no unnecessary copies that kills performance, with static type checks, etc), he'd eventually end up at the same complexity you have now. In other words, there is no breakthrough A.I. compiler algorithm that lets the parser correctly infer how parameters pass through to generic code. If there's a whitepaper that claims otherwise, I'd love to read it. (Rust generics are simpler but they also do less than C++ templates.) The TLDR is that C++ templates is a code gen tool and like any other nontrivial code gen tool, they end up being complicated.

Re: C++11 FAQ

#66
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…

If Rust is slower than the equivalent C++, that's a bug. Please file them.

Re: C++11 FAQ

#67

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…

> ass-backwards closures that's very surprising. I would say that C++ lambda expressions have been an incredible success and probably the best thing to come out of C++11. For example, rust started with boxed closures, because that's what all the 'proper' languages do. They were forced to switch to distinctly-typed, unboxed closures with similar capture modifiers to be competitive with C++ [1].

Your link got eaten, but we don't have capture modifiers anymore. Captures are inferred, and you can override this with a keyword to take all captures by value instead. This still lets you get the same effect as C++, but we find that it's generally less verbose. It depends though!

Re: C++11 FAQ

#68

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've come back to learn C++14 and it's _really_ nice. I love how lambdas, move semantics, templates, type inference, &c work. It leads to much cleaner and elegant code.

I'm still not so sure I like how iterators are designed, but maybe it'll grow on me?

Re: C++11 FAQ

#69

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…

The 'original sin' of C++ is not having both references and pointers, but trying to remain compatible with C.

That means that Stroustrup couldn't have ditched pointers, but if he wanted to implement operator overloading for value types with same efficiency as C he needed some way to support doing that without using pointers directly: http://www.stroustrup.com/bs_faq2.html#pointers-and-referenc... http://stackoverflow.com/questions/8007832/could-operator-ov...

A lot of the nastiness of C++ comes from trying to maintain C compatibility: Special behavior for POD, most vexing parse, .h/.cc file split, everything preprocessor and many other misfeatures. Of course, there's also the flip side of it: if C++ wasn't a near-superset of C, it would have never become so popular.

Re: C++11 FAQ

#70

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…

  #include "parent-comment"
Me too, exactly. C++ has turned to baroque junk. The last useful new feature C++ acquired was to make string literals const. (When was that, 2005 or 6?)

If you're using C++, it's best to stick with C++03.

The rabid experimenters who run the ISO C++ committee should have started their own language 15 years ago, rather than hijacking an industry standard to everyone's detriment.

Post reply on HN