Review: Effective Modern C++

The cover of O’Reilly’s Effective Modern C++ by Scott Meyers promises "42 specific ways to improve your use of C++11 and C++14". I had a subtly different motivation for reading it: basically general improvement in my knowledge of modern C++.

I actually first learned object oriented programming by teaching myself C++. You would think that since that was in the late 1990s that my decades of C++ experience would be an asset. Turns out, not as much as one would hope. About the time I was doing some heavy duty things with C++ its creators were busy rearranging it. A couple of years ago, I was confronted with some "modern" C++ and I could barely follow along.

In theory, they had made it "easier" of course. In practice, I’m not so sure. (The N4659 C++17 standard is 1622 pages long!) For those of us who know how to use pointers, allocate memory scrupulously, and comfortably micromanage things, messy obfuscatory changes weren’t necessarily comforting. My philosophy is not far from, if you don’t understand what you’re doing, you probably shouldn’t do very much of it. But that is not the new ethos of C++!

Whatever. That’s fine. It can not be contradicted that old C++ was damn inscrutable and harsh. So much so, that I suspect it might be easier to just reimplement what C++ promises in plain old C. Regardless, I do need to be fluent in the modern C++ idioms so when I saw this book, I put it on my wishlist; when I started my new job, a copy was coincidentally lying around in my office! Yea! I figured that maybe I could get comfortable with the modern approach and feel better about the language.

That didn’t exactly happen. I did come to understand the benefits and liabilities of the language features that had been added since I first learned C++ so many years ago. But I didn’t get the feeling that everything is ideal now. Part of the problem is the unsettling tendency that the C++ standards committee will inevitably keep morphing the language making it very hard to get settled for the long term. For example, imagine you had been trying to keep an OS kernel going since 1993 to the present — C++ would have been a disaster.

By reading this book, I was able to fill out my extensive C++ Notes with all the modern bells and whistles. To put it that way is kind of misleading. The modern trappings are far from minor decorative accoutrements, but rather a profound shift in how most practitioners actually write code. I have come to believe that modern C++ programmers have bifurcated into two "classes" (ahem): experts and the non-experts. Putting it simply, the experts write libraries and the non-experts (try to) use them. The experts must know gory hideous details that make old C++ (and very old C) seem simple and charming. The non-experts are doing their best to have no idea how C++ works at all — they just want to get on with their work in some other domain.

Hence new arrivals like auto for assigning types to variables. C++ is, in theory, a strongly typed language. But if auto, in practice, eliminates the need to fastidiously plan data types, then something seems not quite ideal for Team Strong Type. The fact is that auto creates all kinds of horrendous mischief for the aforementioned experts and greatly simplifies things for the non-experts. I know about the mischief because the entire second chapter is dedicated to this topic.

My personal goal was to learn briefly everything involved in what the experts must deal with, but only so that I can make better choices as a more ordinary user of various libraries. For that this book was ideal. I could follow along with about 95% of it but I’ll remember only about 5%. I do, however, believe that my intuition is now much better about modern C++ arcana.

I almost felt sorry for the author — what a terrific intellect wasted on the minutia of this raspy programming language! But I hope he has a good job and is happy with having climbed to the top of this obscure austere intellectual mountain. The book’s organization and writing were very good. What I really appreciated was the author’s humanity. No pretentious bombast here from someone who clearly knows a lot more about a complex topic than any of us little people. The humorous deprecation he unloaded on the language from time to time definitely kept it real and let me know that he understood that someone like me would find a lot of the "simplifications" absurdly complex. If you learned C++ in the stone age like me, this book is good. If you’re one of the hard core folks who writes OpenCV or TensorFlow or something like that, knowing everything in this book probably is mandatory. If you’re simply using OpenCV or TensorFlow, you can probably skip this and muddle through.

Here are some of my favorite bits.

p97 P1 S1: "If there were an award for the most confusing new word in C++11, constexpr would probably win it."

p109: "Yes, yes, ancient history: Mesopotamia, the Shang dynasty, FORTRAN, C++98. But times have changed, and the rules for special member function generation in C++ have changed with them. It is important to be aware of the new rules, because few things are as central to effective C++ programming as knowing when compilers silently insert member functions into your classes."

p149: "But I’ve shown you C++98 code, and that reeks of a bygone millennium. It uses raw pointers and raw new and raw delete and it’s all just so… raw."

p158: "No matter how far you dig into [move and forwarding semantics], it can seem that there’s always more to uncover. Fortunately, there is a limit to their depths. This chapter [5] will take you to the bedrock."

p170: "That’s the kind of behavior that can drive callers [of member functions] to despair — possibly to violence."

p181: "This leads to behavior that’s intuitive only if you’ve spent so much time around compilers and compiler-writers, that you’ve forgotten what it’s like to be human."

p181: "That function will [do a bad thing], your compilers will throw up their hands in exasperation, possibly punishing you with long and incomprehensible error messages as an expression of their displeasure."

p191: "If you’ve never seen anything like this [code] before, count your blessings."

p195: "The resulting error message is likely to be, er, impressive. With one of the compilers I use, it’s more than 160 lines long. … The more times the universal reference is forwarded, the more baffling the error message may be when something goes wrong."

p205: "The motivation for the SSO is extensive evidence that short strings are the norm for many applications." [Good for many applications written by normal programmers?]

p219: "[You may believe] Only loser C++98 programmers use raw pointers and delete. That may be true, but it’s irrelevant because you do, in fact, use raw pointers, and they can, in fact, be deleted out from under you. It’s just that in your modern C++ programming style, there’s often little sign of it in the source code." [Some hints about the degree to which C++ hides the truth.]

p239: "When bind was unofficially added to C++ in 2005, it was a big improvement over its 1998 predecessors. The addition of lambda support to C++11 rendered std::bind all but obsolete, however, and as of C++14, there are just no good use cases for it." [That was an easy one! I missed it completely!]

p248: "Instead, you have to call a timeout-based function — a function such as wait_for. In this case, you don’t really want to wait for anything, you just want to see if the return value is [deferred], so stifle your mild disbelief at the necessary circumlocution and call wait_for with zero timeout…"

p252

[If someone told me this syntax was a joke, that would be easier to believe, but no, it’s real modern C++ — at least for programmers who wouldn’t just use 1e7.]

p263: "The first issue with this approach is what’s sometimes termed a code smell: even if the code works, something doesn’t seem quite right."

p291: "Because you’re a C++ programmer, there’s an above-average chance you’re a performance freak. If you’re not, you’re still probably sympathetic to their point of view. (If you’re not at all interested in performance, shouldn’t you be in the Python room down the hall?)"

Here is a parody image I made for my C++ notes long ago that is supposed to be humorous, a joke.

But now that I look at it, the humor is really too dry — C++ is so ridiculous that this is a very plausible book! (And my notes show an earnest attempt at starting that project.) Modern C++ is a mess. Meyers' book has shown me that my misgivings about it (which are very similar to Linus Torvalds') are not completely unrealistic. I feel that C++ is too muddled and baroque to compete with truly helpful (but generally slower) languages like Python (or even Bash) for simple prototyping or organizational tasks. I feel like it loses to C on performance by definition. For me none of the "features" of C++ make programming "easier" than programming in C. I am thankful that I had the good sense and luck to start my serious programming education by reading K&R cover to cover. To me C++ seems an unnecessary monstrosity. I think this mess is sadly shackled to (and evolving away from) the one fact that completely exonerates C++ as brilliant and sane, and the reason I’ll continue to happily use it with a smile on my face: at least it’s not Java!