Thinking in C++ : Introduction to Standard C++, Volume One Book

Bruce Eckel, Thinking in C++ vol. I (Prentice Hall, 2000)

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. ****