Bruce Eckel, Thinking in C++ vol. I (Prentice Hall, 2000)
[originally posted 4Feb2002]
This is what so many other books about the process of programming C++ could have been. Eckel uses the most up-to-date C++ standards, the strictest programming techniques, and takes enough time to explain both the how and the why of the things that he’s talking about in enough detail that the user, while perhaps needing to read certain sections two or three times to really get the gist of them, should have a thorough understanding of the subject by the time the reader has finished the section. This leads to a complete absence of the usual “here’s what to do, don’t worry about why you’re doing it until we get to chapter X” found in most programming books. It also stresses programmers developing their own programming style, but imposes the strictures called for by the ANSI C++ standard. Sometimes too much freedom IS a bad thing, and that’s the case with the vast majority of books on C++ programming. Individuality is important, but clarity of code is important, too.
The book has few shortcomings. The section on namespaces could be a little clearer considering a number of the prospective readers of this book are less familiar with them than they are with most of the other concepts covered here, for example. But the shortcomings are few and far between.
The most important thing about the book, though, is that Eckel uses the book’s style and presentation as a physical model of abstraction, the most important move any programmer makes from a procedural language to an object-oriented language. The astute reader will pick up from Eckel’s discussions of the philosophy of programming an understanding that not everything is about code, and that code is not the be-all and end-all of the programmer’s job. A lot of it, especially in the design stages, is concept. Many of us in today’s workforce, especially those who have spent whole careers doing nothing other than modifying existing code, forget that all too often. We’re stuck in reactive environments, where the company believes that keeping things running is more important than improving them. A grounding in the design concepts presented here may allow more adept programmers to turn a reactive situation into a proactive one—being able to keep things running at the same time they’re being made better. And that’s how it should be. ****
* * *
Bruce Eckel, Thinking in C++, Second Edition, volume 2 (Prentice-Hall, 2002)
[originally posted 26Feb2002]
(note: this is a review of revision 4.0, an incomplete version.)
Eckel continues with the definitive work of the zen of C++, getting into the more advanced topics and newer things that dinosaurs like me haven’t even begun to assimilate yet (read: the Standard Template Library, by far the most complex ANSI C++ standard to date). Where volume 1 of Eckel’s work should be required reading for all C++ programmers, think of volume 2 as the intriguing, but not yet useful, sidekick. Your first run through this book will likely leave you scratching your head in confusion. There is much here to be learned, but it’s going to take a number of readings to really assimilate it all. How much more advanced are we talking? A small piece of comparison: volume 1 took me about three days to get through, with only a few places where I had to re-read, pause for reflection, or consult other sources to grasp what was there on level enough ground to write a review. Volume 2, on the other hand, set me back almost a month. Tougher? You be the judge.
This is not to say, by any means, that you shouldn’t read the book ASAP. Even touching on the surface of some of the things here is likely to give both beginning and experienced programmers the sparks of new ideas about how to go about their day-to-day tasks; the chapter on design programming alone is well worth the price of admission. Unless you’ve already read Design Patterns, the seminal work in the field, most of what’s here will probably leave you wondering what in the world Eckel is on about, especially if you haven’t figured out all that template stuff. However, Eckel’s easy-to-read style lets the reader know that not only is there a lot more to be uncovered with successive readings as the reader’s knowledge expands, but that design concepts can start being changed now in the abstract, so that the reader will be ready to go ahead and modify once he’s got the specifics down at some future date. And really, that’s what object-oriented programming is all about: making allowances for future expansion. ****