Bjarne Stroustrup

This book is upside-down from almost every other programming reference book I've ever read. Usually books like to start you at the ground level: if it's a book on C++, you get memory management and pointers; if it's on basic coding, you get sorting algorithms and linked lists. If it's on generics, you generally get implementations of iterators.

What this sort of book never points out is, you shouldn't ever need any of that nonsense. C# and Java have a zillion standard library collection show more classes that implement iterators. Every halfway modern language has a linked list class. And in C++, you hardly have any need to do any memory management - if you use the standard template library.

This is where Stroustrup is coming from. He starts you at the very beginning, learning how to use the std::list class just like you would do if you were using it, intelligently, in an actual application. That's more or less how the whole book is organized: practical, sensible applications of standard templates. Not implementations of iterators (although that's in here), not memory management; just writing code in the way Stroustrup envisioned code being written when he designed the language.

So, if you want to write code the way Bjarne thinks you should write code, read this book. show less

(Original Review, 2001)

Back in the day, I started programming AMOS on Commodore Amiga500. It was almost exactly like QBasic, but was able to do more powerful graphics and sound in an easier way, though still extremely similar. Because of how slow those CPUs were, I had to always try to find ways to make the programs run as fast as possible. And then I started programming QBasic on a 200Mhz PC, still being focused on trying to get as much power as possible in my programs. Around 2001 I show more started with C++ by using Stroustrup’s book, and even though we had a lot of power, I was manically trying to make everything as simple and efficient as possible, to get all that power out, even though I was on a powerful i7 with a GTX780. Whenever I thought of using "smart pointers", I always thought that I'll just use ordinary, low-level pointers, because I don't want to incur any overhead whatsoever. Check if a pointer is OK? Screw that, it'll cost me! Better to make sure it doesn't happen, rather than to check if it did happen, by being smart about it. I do simulations and experiments, and things like 3D game engines, and I wanted every little bit of performance I could get. I wanted the code to be perfect, so I kept re-writing everything, and I was afraid of using libraries that might have unnecessary overhead, like error checking/prevention, so I re-invented the wheel over and over. It's important to note that it was a hobby back then (still is, but less so). I wouldn't do it like that if I was going to share the code, or release a product (there was no psychologist available who could have helped me get over this obsession...)

The main problem is what I feel must still be tackled towards the end of reading Stroustrup's book: there's a lot of baggage from C, not on the spec, that's the least of the problem, but on people's minds when they code or of course when they reuse old code. When I started learning C or C++ programming, and it wasn't that far back, there was either material on pure old C or C++ that was almost identical to C with a few class definitions thrown in (and C fanatics pushing newbies to learn C instead of C++ for every project doesn't help and is simply insane).
At the end of the day C++ is abysmal if it's written like C since the only thing it gains is a couple of class definitions. The true power of newer languages is automation and abstraction above the micromanagement of C. Sure, that micromanagement might make sense when writing the Linux kernel, but for almost every other project it's a total waste of time since it doesn't even increase performance.

I've always felt there is no way around it that C++ has some serious design limitations and the developments of the last years only try to cope with some of them. It is no wonder that there are so many code analysis tools and everybody uses some of them. Apart from that, cross-compiling is still an issue, compiler output is cryptic and setting up a C++ workflow on Windows is ridiculous. I think Rust really has something. On top of that, the syntax is hideous. C syntax isn't perfect and certainly can be abused, but it's simple. With C++, they keep on extending it. How many new ways do you need to do casts?

C++ is not just for higher level it goes pretty deep and down to the bits as well, you can also code assembly with C++ - don't think small with C++ it is a tremendously large language and nearly impossible to master everything involved with it, people who have their PhD's still don't know everything that can be done with it - Bjarne even says he is surprised with what people can do with it - and the standard is always changing, what I am saying is - you should always be learning and never get stale, if you think you know everything go read "exceptional C++" - if you are good with that go run a project on github or get a job, if you have a job learn from those who are great.

Bottom-line: C++ allows a programmer to make mistakes, assumes he knows what he's doing, gives too much freedom and it's bad for safety. If you will learn 10 different programming languages, you will understand what I'm talking about. What can C do that C++ can't? You can do pointer arithmetic in C++, also unsafe casting, arithmetic overflow before allocation, corrupt the heap, return a local by reference, the list goes on, for both languages. The nice thing C++ gives us is smart pointers, but if you want to stay safe you have to subset the language, which raises the question: why use C++ then instead of a higher-level language that more accurately reflects your usage? Yes, C is a little more comfortable, "simpler", as you say. But that's only until you make big programs, where C allows you to make more errors/bugs, and it has less abstraction possibilities, so there's more stuff you need to keep in your head. The good thing is that you can use C++ in the same way you use C, if you want to, and you can mix stuff quite freely. If you tell your compiler that you're strictly using C, then you have less freedom. Even if you tell your compiler to strictly use C++, you can still use C++ in the same way you'd use C. OOP is optional, though it's sort of the point with C++. I think the difference between C and C++ becomes clear when you look at type-casting, for example. In C, when you want to type-cast, you might write "int x = (int)a_float;", to cast that float to int. But in C++, you have to explicitly state what kind of type-casting you're using. Reinterpret, dynamic, static, const. And the thing is that those 4 different type-casts exist in C, as well, but you never explicitly state which one you're using. In C++, it'd be "int x = reinterpret_cast(a_float);". As for "the debate", I didn't know there was one. C++ is clearly a better choice than C, since you can still do what C does, but you've got more, as well. Some say "but C is faster", and that's in a sense true, but C++ can be as fast as C, if you avoid those few things in C++ that make it slower. The freedom is there, without any drawbacks. That makes C++ the obvious winner.

That's why I'm all for using Python. Much safer. show less

All other textbooks in this category of which I am aware are downright bad; misleading, error-filled, and incoherent. This book is well-organized and thoughtful. The presentation is a good approach to teaching the craft of programming instead of a garbled mess of syntactic points and confusing caveats. The author even makes a convincing case for learning to program in C++ and I find myself warming, slightly, to the language itself.

Chapters 6 and 7 may be too much of a mental overload for show more most students. They present successive attempted solutions to the problem of designing a simple calculator. Unfortunately, the presentation requires the student to understand and agree with the incorrect solution proposed and then deconstructed and improved. The likely result is simply confusion on the student's part. Since my class is small, I can rely on the student solutions containing all sorts of errors. These will provide the fodder for analysis and improvement, and will work better than the author's made-up example. The author is now a professor at Texas A&M; the introductory class is large and it's impossible to give student solutions individual attention.

The author uses the newline character as a line separator. This is weird, given his obvious enthusiasm for abstraction I would have expected him to use endl. If he explains this preference anywhere in the book I haven't seen it.

This book receives five stars because it is so superior to every other introductory programming in C++ textbook I have encountered rather than because it is unflawed.

==========================================================================================================

26. Testing

26.1 What we want.
26.2 Proofs. Tough. Pace Hoare.
26.3 Testing.
26.3.1 Regression Tests - for catching regression, of course.
26.3.2 Unit tests.
Develops a simple framework for running unit tests. Advises to separate examples from the runner. Shows how it's possible to generate random tests (write stuff into a file).
26.3.3 Unfortunately, most functions are written by people who have only a vague idea of what the functions are supposed to do. How do w test those? There is also the added problem of hidden dependencies. Maybe if we find enough bugs someone will figure out a better design. Resource management in C++ is a quagmire, and a good source of bugs for testers to find. Loops and branches are hard for some, but not if you have that strong formal methods background, so not for me. Of course, one must always remember the dreaded C buffer overrun.
26.3.4 System tests. That kind of thing is hard. For GUIs, better to separate the GUI from the engine, so that you can test the engine in isolation.
26.3.5 Testing classes. This is the pointless section.
26.3.6 Finding assumptions that do not hold. How to verify that the preconditions of a method are satisfied whenever it is called.
26.4 Design for testing. Of course.
26.5 Debugging. One paragraph --- "definitely hate debugging." I guess I'm on board with these guys on that one.
26.6 Performance. Don't be stupid and convert a linear algorithm into a polynomial one through inattention (there are some obvious examples). Otherwise, don't optimize prematurely. For timing, use clock().

Not much useful for someone like me, except for the reminder that C++ is like C so, buffer overruns. show less

You do not need to read this book to code in C++, you need to read it if you want to know what your code is doing and why. This book is not patronizing, it does not include humorous quips, it does not apologize for using appropriate language. This book explains what C++ has to offer, why it has it, and how to use it. All of it. If you code in C++ do your fellow coders and future code maintainers a favor and buy it.