It's the worst programming book I have ever read! It's introduction made me hate C++ and if I didn't had to work with other C++ libraries, I would have avoided C++. The text is full of bloat, for the lack of better word. It's the opposite of crisp writing.

I read some good language books like K&R's C, Joe Armstrong's Erlang book. I loved them and I thought this would be in same league. It's not.

I would like to learn C++ systematically, like not cut-and-paste stuff. "How to think like a computer scientist: C++" seems like a good book. I read the book "How to think like a computer scientist", which is an introduction to programming in Python. I think that would be a good start. Is it a good book for experienced programmers wanting to learn C++?

To people wanting to learn C++, please avoid Stoustrop's book like Plague.

EDIT: I read "The C++ programming language 4th edition" which explains C++11 https://en.wikipedia.org/wiki/The_C%2B%2B_Programming_Langua...

You mean somewhat similar to the programming language the same person developed?

You may find his book "Principles and Practice Using C++" [1] more accessible.

[1] http://www.stroustrup.com/programming.html

You nailed it with that analogy though.

K&R is a "first book" and important historically, but right now it's an atrocious book if you want to learn current C and this has been the case for a long, long time.

Sometimes these first books don't withstand the test of time.

K&R may be archaic now, even obsolete. However, for decades it has was held up as a an example of what a good technical/language book could be. You don't have to agree with the assessment to agree with the fact - that this was touted as a very good technical book for various reasons.

There never was a "K&R" of C++. That's not unusual, many languages are in the same boat. If you want to go back to the "firsts" it would be a combination of The C++ Primer and Strousoup, putting them together gave you something that was both more and less that K&R was for C.

From the software engineering point of view, almost every single code example is terrible. Abundant implicit casts depending on the OS, loops that leak buffered reading between iterations, etc etc.

Just no. Never, ever recommend K&R to anybody as a general programming book neither for C or in general. Only the intro descriptions of language characteristics and important functions of the standard library are any use, and then again even these are extremely obsolete now.

There is, however (like or not), a reason we even now say "X is the K&R of Y". As such it is a bit silly to claim that the only reason K&R succeeded as well as it did was by being early....

Strongly disagree.

1 - http://knking.com/books/c2/index.html

There's not a whole lot that's changed in C11, (C is kind of "done" at this point) and there's not been a newer book that teaches the language so well.

Not to be confused with C++ Primer Plus.

One drawback may be it's age; it's 17 years old. On the other hand it was way ahead of it's time and good writing doesn't get old.

(ps. I quite like Stroustrup's books but to each their own)

    [0] https://en.wikipedia.org/wiki/Open-source_license
    [1] https://theboostcpplibraries.com/
    [2] http://greenteapress.com/thinkcpp/index.html
    [3] http://opendatastructures.org/ods-cpp/About_this_document.html
    [4] http://www.network-theory.co.uk/about.html

Another important thing, no matter how many books you read, you can't be a master without actually solving a lot of problems.

Questions from learners are often poorly formulated and then poorly answered. Since many people are just looking for getting their code to run or finishing their homework, this sort of stuff just piles up without getting fixed.

If you're trying to learn anything non-trivial, don't rely on SO alone.

[1]: http://stackoverflow.com/documentation/c%2b%2b/topics

On the other hand, people like Scott Meyers have spent their lifetime and careers explaining its intricacies, without solving any real problems.

It can be misleading to think of standard header code (especially template code) as "idiomatic C++". It'd be better described as "idiomatic standard-library-implementor C++", since the folks implementing stuff in std are operating under a whole set of constraints that don't affect ordinary C++ programmers. Arbitrary user-defined symbols that could be in scope, user-provided types that could have overloaded operator-comma, etc.

Designers and implementors are traditionally under a very different set of constraints than "average users" (who in this case are programmers), though their goals do align. But this leads to very different set of assumptions, optimizations, and tools being available. Things that would generally be overkill are suddenly very viable and worthwhile goals to achieve (e.g. micro-optimizations add up repeatedly so they're very worth it, vendoring is much more useful to control dependencies/scope of bugs), and vice versa.

So I wouldn't be extremely miffed if you look at libstdc++ or libcxx or <whatever> and find it somewhat unkempt or gross compared to average code. It's often very much not-average. In fact it's likely given careful understanding of the constraints that code exists under -- you'd come up with similar results.

And what's with the Scott Meyers ding? I think of him mostly as an educator and in that respect he's very accomplished.

Each time I hear a discussion between programmers, it is always these arguments of whether build tool A is better than build tool B, or whether VCS A suits their workflow better than VCS B, or how cool is the latest language feature. I never see programmers discussing the merits of their solutions, regardless of the language or environment.

What we don't have in common are the exact problems we are trying to solve. That's where design patterns and other higher level concepts become useful. Because the problems and solutions are so context specific, they happen on mailing lists. Tool discussions, on the other hand, are more generic and I think that's why you see them in more places.

Sometimes people think they know their favorite language, but most would fail a language puzzle quiz.

Right, I'm sure Go is the one and only language out there without a single pitfall or quirk.

But that is especially true for C++. People who are confident in knowing it often lack the fundamental C knowledge (i.e. pointer arithmetic, the complete C type system, the subtle conversion and promotion rules, etc.), but would insist on knowing C++ very well just because they know how to define classes, virtual functions and throw a shared_ptr or a vector or a map at every problem.

Nor can they correctly point out all the cases of expected semantics, UB and implementation specific behaviour.

Regarding the fundamental C knowledge, part of it just leads to bad C++ code.

In C++, you fight with the language first and then face the problem.

It's such a complex language brimming with idiosyncrasies that I'd be inclined to really test anyone claiming to be a master. The standard is one thing, then there's the compiler you're using...

Also a programming language is not used alone and C++ standard library is quite tiny when compared to Java's standard library.

Even parts of C++ that are "normal user" features can be remarkably tricky. I know tons of C++ programmers who I'd happily trust to write code for me who would fall flat on their faces if asked to explain some detail of what std::forward does with an rvalue reference parameter bound to an lvalue argument.

There's a reason why a very common recommendation is to pick a subset of C++ and stick to it, and I've never heard of such a recommendation for any other language (outside of perhaps for portability reasons).

That is true.

I can also remember other ones like differences between auto and decltype, or between auto and template parameter deduction across language revisions.

However, Java puzzles like the ones presented at Java ONE, or .NET changes in how native error handling changed on .NET 4.0, among many other examples, are also interesting as quiz questions.

And it's under active revision and improvement. There are great new things to learn every few years.

And to be frank: I'd say that anyone opposed to continue to learn new things is entirely in the wrong field if he/she works on any technology-related job.

However, constantly learning and updating things has its drawbacks. One of the rare times I tried to be hip and use the latest stuff, I tried rewriting parts of a small Android app of mine using java 8 and lambda closures. I made it work, but it required upgrading my minimum build version (locking out older devices), the compiler could barely handle it (gave some strange indecipherable errors relating to lambdas), and ultimately it was just a step backward. That kind of thing really frustrates me, because it's wasted (at best, deferred) effort.

Being conservative with new additions to your codebase seems a bit backward, though. Why not use the new, improved shiny language feature™ if you can?*

Of course, if you are prohibited by business requirements (e.g. missing modern compilers for a certain target platform) that's another story. Basically, it always comes down to practicality.

* A prime example would be the new way you can implement Singletons with C++11. Once you've used that, you realize how horrid pretty much all C++98-based attempts at this are.

Yes, I realize Singletons are often a bad idea.

You don't keep learn new stuff because C++ is super, uber, powerful. It is because it is not designed well and there are far too many dark corners.

Have anyone read it and know how it compares to the books recommended in this article?

http://cglab.ca/~morin/teaching/5408/ https://github.com/patmorin/tds

- Build a time machine

- Go back to 1988 and get hold of Bjarne's first book and a Zortech compiler

- Grow old, tinkering with and constantly keeping tabs on the language's evolution.

In this way, what seems to the modern neophyte like a massive indigestible meal is actually presented as a procession of smaller courses, most of which are an improvement on the ones preceding.

Open source at: https://github.com/jeremyhansen/rooksguide-cplusplus

Previously discussed at https://news.ycombinator.com/item?id=6806598

Full disclosure: I joined as a technical editor on the kickstarter just before publication.

I thought Eckel's book was especially good for someone who already had a background in C.

I have one question though, Is there any pdf version for "The Boost C++ Libraries"? I really need it.

Theres a lot of good stuff in there..

Just get: src/base, src/ipc, src/net (and something else you are interested in) and you are good to go

https://www.chromium.org/developers

Then, if you need more, you will have to do it the "hacker way", by reading the chromium source code.

But hey.. you are a C++ dev, source code should be your stack overflow, and primary source of "documentation".

hint: The unit test files, can make the "how to use this" much more obvious

Also it can break any time.

Now, if you want more functionality than that.. like access to the last blink/webkit api, than you will suffer a little bit.

C+ - No idea.

C++ - C with a bunch of stuff added on (mainly OO, other goodies too). Still no GC.

C# - not related to C at all. It's basically Microsoft's Java, with GC, OO, higher level constructs, lots of sugar, etc...

Both Rust and Go (big in China) are worth looking at. Unless you're doing games programming C++ is neither C/ASM (which is popular for hardware) nor Java/C# (popular for business software) or PHP/RoR/Java (popular for web back ends).

Plus when you learn C++ you don't have to learn one language, it is more like learning four or five as they completely re-invented the language every time a standard ships. This might sound good, except a lot of these constructs are a pain in the butt to intermingle.

Furthermore, I'm not just talking about the existence of a standard, but the complexity of the standard (C++is v. big), and also how much that standard restricts, and hence results in conformal, predictable code.

You mean C++03, C++11, C++14, C++17? Or something else?

If you mean those, I fail to see the problem. The language isn't dead, so it's not static, and it evolves over time. Publishing a new standard every few years is the only way to keep all compilers aligned, rather than each going off in its own "with extra features!" direction.

The standard already has lots of features, including a turing-complete sub-language.

It is difficult to write code to standard (nothing that works, but is undefined either), that is safe, no segfaults, memory issue, secure, and all within a practical budget/timeline.

Just being able to reason about the code more easily helps, or make strong assumptions (e.g. about safety).

Do you know by heart the differences between each Ruby, Python, C#, Perl ..... version?

Your argument is similar to: "Hitler is bad, but no one if perfect" - does that mean than anyone not perfect is equivalent to Hitler?

Moving on; to focus on python it's not difficult to know the handful of changes between, say, python 2.5 and 2.7, nor to understand them. py3 is different, and the fork caused a lot of controversy, there is still resistance to py3. There is a python-2-to-python-3 tool (could any such thing practically exist between C++ versions?), but it's not perfect.

A language like Java almost suffers from trying to remain backwards compatible, yes a) the feature is nonetheless appreciated, and java is heavily used and praised in 'enterprise' b) Java tends to make breaking changes rarely, and only when necessary - can the changes between C++ specs be described the same?

exactly! what's wrong with that?