How Not To Program In C++

111 Broken Programs and 3 Working Ones,

or Why does 2 + 2 = 5986?

by
Steve Oualline
Published by No Starch Press

Review by Michael Morin
MELUG-Central A division on MELUG, the Maine Linux User Group

Introduction

One of C++'s worst points is its complexity. It's easy enough to shoot yourself in the foot that this book shows you 111 different ways to do it. The example programs in this book begin by demonstrating simple typos that produce working programs, but give wrong results. As the book progresses, the problems get harder to figure out, demonstrating subtleties in C++'s syntax, its preprocessor, memory allocation and runtime environment. All of these programs demonstrate common mistakes, if you're a C++ programmer, you'll find yourself saying "Hey! I've done that!", and if you haven't, you'll be glad you saw in here first.

Each program is accompanied by a number of hints and an answer in the back of the book. The hints are spaced out so you're not tempted to read them out of order, but having to travel 10+ pages in either direction after reading a one line hint can get annoying after a while. The answers have their own section, but are as equally annoying as the hints, a small section after each section would be preferable to a large section at the end of the book.

Amusing anecdotes about computers soak up the blank spaces between programs. This breaks things up well, after kicking yourself for missing such an obvious problem, having a chuckle keeps you from pulling your hair out.

Comments

The layout of the book is good. Programs start simple, and mistakes are spotted easily. The meat of the book puts your knowledge of C++ to the test, but none of the problems will have you scratching your head for too long. Towards the end, the problems get pretty tough. The last chapter has a few problems related to embedded and threaded programming, spotting these race conditions and how to fix them can be difficult, but thankfully there are only a few of these frustrating programs.

To get much out of this book, you're going to have to be fairly fluent in C++. Beginners will get a lot out of the first half, but the single-paragraph explanations will not help them understand how it's supposed to work. There are few unintentional errors in the actual code of this book, which is somewhat rare. Overall, the book is very polished, with very few typos or grammatical errors, and I noticed only one of the page-number errors that seem to plague books from No Starch Press.

Conclusion

Overall, How Not To Program In C++ is a good book. It's a good read all the way through, and has some practical uses for C++ programmers. Those just learning the language should wait to buy this book, or at least know that most of the book won't do them any good just yet. At the other end of the spectrum, experienced C++ programmers will probably have seen most of these errors already, one time or another. The book will be amusing to them, but not overly useful.