Live data from Hacker News

C++11 FAQ

stroustrup.com

41–50 of 121 posts

Re: C++11 FAQ

#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 well-developed as C++. The amount of resources and existing code in C++ is staggering. Newer languages such as D and Rust simply can't compete.

Re: C++11 FAQ

#42

Earlier quoted context omitted.

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

If you want to template on an r-value reference, the easiest way is probably to use a forwarding reference and disable the template if the template parameter deduces to a reference

    template ::value>>
    auto f(T&& x);

Re: C++11 FAQ

#43
post #9

Earlier quoted context omitted.

What you paint as a fault might be an asset: C++ is multi-paradigm. There is more than one way to look at something and there is a joyous chaos of varied abstractions from which to choose from. Yes it takes a certain openness of mind and a long learning curve. But then, you get to operate at a level that other platforms can only dream. In full disclosure, I do NOT consider myself a good C++ programmer. But I've alway…

How well has Perl fared? How about Lisp and Scala that are multi-paradigm, how well are they doing?

Perl was doing just fine until they fell in the perl6 hole and stagnated. Scala's getting its data science niche, and lisp has a lot more problems than just being multi-paradigm.

Re: C++11 FAQ

#44

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 returned to C++ 3 years ago, having previously used it in the mid-1990s. I tend to agree with you, but I found that it was necessary to forget my old C mindset (pretty easy since it was 20 years old) and start learning modern C++ idioms from scratch.

Eg, back in the days, I could fling raw pointers around with abandon. Now they need to be handled with care, and there are many tools and patterns available for you not to have to deal with them at all.

Re: C++11 FAQ

#45
post #14

Earlier quoted context omitted.

that's because it is impossible. it takes years to master the language and that was before i lost touch with it around 2010 back when C++11 was TR1 or whatnot. i understand that what is usually considered good form is trying to completely forget about C features like pointers and arrays and use their STL counterparts like unique/shared_ptr, std::vector, std::array and iterators. this gets you a nice modern subset of…

I didn't use C-style string functions for the longest time. If I had a char*, perhaps because I got it from some C library we were using, I would turn it into a std::string and use it's functions and operators. One day, I realized how silly that was: I'm sure I was causing gratuitous memory allocations (not all strings qualify for the short string optimization). Perhaps part of my hangup is the expectation that you w…

it isn't possible if you're doing real work, but it is possible if you're learning or teaching, especially if stdin and stdout are the only ways your program will do IO. it's actually pretty nice and code is surprisingly concise, especially if you use stream iterators.

Re: C++11 FAQ

#46

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…

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.

Re: C++11 FAQ

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

Ada.

Re: C++11 FAQ

#48
post #2

Good stuff, I can also heartily recommend Scott Meyer's Effective Modern C++ book which covers idiosyncrasies and some unexpected behaviour (at least to me). Also Stroustrup's 4th edition of The C++ Programming Language is invaluable, if not just for the more-readable sans-serif font compared to the 3rd edition! And of course the coverage of all C++11 changes in it... I can also recommend the Overload journal for int…

I started to read into "Effective Modern C++" but it seemed the book (or at least the beginning) focused too much on obscure edge-cases of C++ for me before I stopped reading. "Effective C++" didn't feel that way for me and many tips were useful on a day-to-day basis. Is this just me or did you have a similar experience? I read those books quite some time ago so my brain could also wrong me here...

Re: C++11 FAQ

#49

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 is a different language. Learn it ;) And move semantics is a good thing. If you are fed up with C++ though - try Rust.

Re: C++11 FAQ

#50

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

What if a hypothetical new operator used only characters already not allowed in identifiers and composed of characters not allowed in contiguous operator sequences.

Consider: :=, <-=, <|, $,

Post reply on HN