Dr. Dobb's Journal December 2000
One of the ironies of the open-source/ free-software movement is that, while source code, tools, and information are widely available and free (as in both beer and speech), the compiler suite of choice for the vast majority of such projects is, at best, poorly documented. It's probably not an exaggeration to say that many of the people using the GNU C/C++ compiler and associated tools are unaware of the majority of the tools' capabilities. Programmers in the OS/FS arena are similar to nearly all of their siblings throughout the industry who are given a choice -- the code comes first, and later, if we're lucky, good documentation appears. All of which makes books like Tom Swan's GNU C++ for Linux, by Tom Swan, all the more intriguing.
Most readers know Swan as a former DDJ columnist and author of more than 30 books. Luckily, this book employs his usual thorough and comfortable (if not scintillating) style. But it's only fair to ask: Is the book nothing more than a rehash of his prior C/C++ work with a "Here's GNU" chapter slapped on the front? No. Swan includes a lot of detail about the GNU compiler suite, including many hints and tips about where GNU C++ might differ from other C++ implementations, such as his discussion of the different ways compilers handle code generated by templates. The GNU-specific material does taper off noticeably as the book progresses, but that doesn't really detract from its value.
Swan begins the book with crash courses on installing Mandrake Linux and the GNU tool suite, then segues into Section II, an eight-chapter introduction to using GNU C++ for purposes other than OO programming. As he does throughout the book, Swan makes a subtle effort in this section to encourage good programming practice. Some of his recommendations, such as using parentheses to make expressions clearer to people (even if the compiler doesn't need them) will no doubt strike many of the more testosterone-driven C/C++ programmers (and you know who you are) as being quaint. Speaking as someone who's spent more than his fair share of time working with hacker-level C/C++ code written by others, I can only hope Swan's readers take his message to heart.
Sections III, IV, and V are an introduction to OOP (classes, creating/destroying objects, inheritance, exception handling, and templates), advanced C++ (function and operator overloading, I/O stream customization, and a catch-all chapter on miscellaneous C++ topics), and class libraries, particularly the Standard Template Library (STL). These three sections -- totaling 16 chapters and nearly 450 pages -- are the heart of the book and give you the greatest return on your investment of time and money.
Throughout this portion of the book, Swan presents numerous example programs, both positive and negative (all included on the book's CD), and generally concentrates on real-world issues of clarity of the source code and program efficiency. Even programmers who know C inside-out and are experienced with C++ will find a lot of value here, particularly in Swan's coverage of the String library and the STL.
The one glaring anomaly in this book is Swan's treatment of X programming, in Chapters 26 through 30. The first three chapters cover X basics, while the last two are about using the open-sourced V application framework. Considering that one of the big Sumo matches in the Linux world is between the desktop environments KDE and GNOME (and their respective toolkits, Qt and Gtk+), it's odd that Swan chose to virtually ignore both and focus instead on a relatively unknown package. Perhaps Swan didn't have the room to cover even one of the toolkits reasonably well in a book of this girth, but it's still hard to justify spending over 50 pages on the toolkit V.
While Swan does a nice job overall in making this book a solid tutorial, a little more reference material would have been useful. For example, almost any gcc/g++ coder could use an appendix with the author's comments on most of the command-line options for the various programs in the tool suite. (Enter the Linux command "man gcc" for a sample of just how many options are involved. It's a stupefyingly long list.)
Some readers will feel cheated that this book doesn't cover Linux programming, per se, but rather programming with the GNU C++ compiler. There's nothing here about Linux system calls, what information is squirreled away in which corners of the /proc file system, or dealing with command-line processing or pipes, among many other topics. This view is misguided, since the book's goal is to cover the tool, not the environment. Plus, there are several books available that do present system-specific material in some detail. The most useful approach is likely to combine Swan's book with one of those, such as Beginning Linux Programming, Second Edition, by Richard Stones and Neil Matthew (Wrox Press, 1999).
Tom Swan's GNU C++ for Linux isn't a book for you if you are already a black belt in C++ and just want to come up to speed with the GNU compiler suite. But if you're a C programmer/C++ dabbler interested in expanding your capabilities and picking up a little Linux along the way, this book is definitely worth consideration.
-- L.G.
Except for a few discussions involving components and trade-offs, Scott Ambler's Process Patterns is close to being a classic on OO system-development processes. Indeed, it is a very solid reference. When I came across this book, my first thought was, "Uh-oh, Scott has sold out to the Design Patterns/UML/Object Factory book of the month." Not to worry. The subtitle, "Building Large Scale Systems Using Object Technology," should have clued me in right away. Ambler is sharing in Process Patterns better processes for getting object-oriented systems developed on time, on budget, and on spec.
Process patterns, like design patterns, seek to identify better methods or best practices for building OO systems. And as Ambler's sidebar "War Stories" attests to, building OO systems is fraught with both general and unique challenges. Since the object design principles and OO languages such as C++, Delphi, and Java have gained ascendancy, more and more organizations are building large-scale OO systems. To that end, Ambler assumes you are reasonably familiar with OO methods and tools; so he spends the core of the book on identifying better processes for doing OO development.
Ambler's emphasis is on good project processes, not any specific language or methodology. And the themes and phases are familiar -- Initiate, Construct, Deliver, Maintain, and Support. But the way Ambler strings these development phases together is both novel and important. He argues that OO projects tend to progress serially overall, iteratively in the detailed stages, and deliver incrementally rather than in one monolithic system. In effect, what OO design has done is bring the capability to deliver projects in subsystems or components much more effectively than in structured or even modular design.
The reasons are simple -- structured design is highly hierarchical, proceeding from the top down through both a monolithic processing and datastore/data space point of view. Modular programming breaks down the processing into distinctive subsystems, but the data model is either monolithic or united by message passing through global, public memory pools. The key insight of OO development is that data and processing are linked tightly together, and persistent storage models have to be treated with precision. In effect, OO is perfect for building self-supporting subsystems, or components.
And of course in the era of the Internet, where system development has to contend with the most difficult of data processing problems -- n-tier, distributed, heterogeneous systems in a context of changing GUIs, output modes, and stateless, synchronous plus asynchronous processing -- OO's components look like godsends. Building reliable, scalable subsystems that cannot only perform in cross-platform contexts but also be readily extensible (for instance, being able to accept and process new objects and messages with minimal disruption to a total system) is Object Nirvana.
Ambler recommends an OO software-development process geared towards building with components. He sees project management, risk control, and quality assurance as being key ongoing tasks throughout project development. In addition, he adds another "glue" process -- reuse management. Reuse has a rich set of choices to work from starting at code libraries, object inheritance, templates, components, frameworks to much broader artifacts, and design patterns. In addition, Ambler uses the Software Engineering Institute's Capability Maturity Model (CMM) to help document how reuse of components can benefit projects in a number of ways.
But at this point the book falters like its distinguished predecessor, The Unified Process Model by James Rumbaugh, Grady Booch, and Ivar Jacobson (Addison-Wesley, 1998). The problem is the classic chicken and the egg scenario. How do you partition a system into well-fitting components when you don't know what the size and scope of the system is? But the size and scope of the system in turn partly depends on what components are available to build it. The questions that OO software development needs to answer are: How do you partition a system into set of well-fitting components? How do you identify existing components and map them onto an evolving system design effectively? And, of course, the OO-system process needs to identify the metrics for measuring "well-fitting" and "effectively" beyond the current cohesion and coupling concepts. Sorry to say, but both Ambler and the Three Amigos hint at -- but do not tackle -- this tough nut straight on.
Still, Process Patterns is a well-written book. Its many tables and diagrams make very clear the methods and processes Ambler is arguing for. The advice is solid, well reasoned, and supported by excellent references. However, Process Patterns does a curious thing. After an excellent introduction to the CMM model, Ambler includes a CMM KPA (Key Process Area) icon throughout the book to alert you to the fact that the topic under discussion is a CMM KPA. Rarely does Ambler make an explicit comparison to the CMM in that body of text. It is sort of like reuse of components, where we are told they are important and reuse management is an integral part of OO design, but then the "how" and "why" are scarce. Then again, that topic could easily be another book.
In sum, Process Patterns brings a leavened combination of theory, design, and hard-earned practice to the forefront in elucidating the pivotal tasks in OO development. As a project management-oriented developer, it is refreshing to see this topic get its due credit as time and again Ambler points out how good processes payoff in OO development.
-- J.S.
DDJ