[2005-06-07]
How Not To Program In C++111 Broken Programs and 3 Working Ones, or Why Does 2+2=5986
|
||
|---|---|---|
|
Bit of a different book compared to your "typical" programming book, even the ones from a person like Meyers. Goes through a long row of stand-alone code that is broken in one way or another. Your mission is to figure out how it's broken. If you get stuck, you can look up a hint, or go straight for the answer which explains the issue. With the exception of a few examples late in the book (featuring threading which I'm not familiar with), I had no problem with these exercises at all. Doesn't mean I didn't enjoy it, because even if I could figure it out rather quickly most of the time -- sometimes I'd take an educated guess just based on the description of what the program was supposed to do, and get it right! -- there's something that's fun about seeing completely b0rken code. Your mind will travel and you begin to think "Who'd write something like this?". Sad fact, with some of the examples, the answer is anyone of us. To spice things up, there's a stream of funny anecdotes interleaved with the problems. Sure, it's unlikely you haven't heard some of them before, but I'm sure there's something there for everyone, and especially so for the beginner-or-intermediate C++ programmer. The way the book is structured makes it easy to pick up and put down, so it should make for an excellent travel companion, or maybe something to read in bed. The bad? Well, it's a little too much C-in-C++ for my taste. What I mean is that much of the code doesn't actually use pure C++-constructs. For instance, I consider any code using the str*() functions from the C string library as definite "How Not How To Program In C++"-stuff, but there are a lot of examples based around those in this book. If I may go a little over the top, I'd just dismiss such code out of hand and order it rewritten using suitable C++ constructs, primarily the STL. You might argue that there's a lot of legacy code out there so bugs in "C-land" are worth covering, and with so many examples, surely the idea that there's a better way to do it gets across? Sure, but even so I did expect it -- based on the the title -- to be a little more "C++-heavy". Some of the bugs are such that they'd never make it into production code due to compiler warnings, and I noticed on at least two occasions bugs which would never happen to anyone using a syntax highlighting editor (which is...er.. everyone). The Verdict? I had fun, and what's more, I spent a lot of time sending out snippets and comments to my friends who'd come back with "What's that you're reading?", so clearly there was worthwhile material in there. A good fast (two days for me) read, even if those of us who's been around for a while won't learn all that much. Recommended. One more thing; there were some unintentional bugs in the book, I discovered three of them. Errata here. |
|
©2005 Eddy L O Jansson. All rights reserved. All trademarks acknowledged.