Every few years, with remarkable consistency, new concepts, methods, languages, and tools capture the fancy of software developers. For instance, over the past decade we've witnessed the rise (and sometimes the fall) of AI and expert systems, CASE tools, object-orientation, Smalltalk, C++, frameworks, components, CORBA, HTML, the WWW, Java, and recently patterns, which is the theme this month's C++ Report. In this editors corner, I'm going to explain why I think patterns are important to C++ programmers.
A pattern is a successful solution to a set of common problems that arise when building software . In general, patterns aid the development of software by expressing the structure and collaboration of components to developers at a level higher than (1) source code or (2) object-oriented design models that focus on individual objects and classes.
Patterns are particularly valuable to the C++ community because they help to clarify good solutions to forces that often befuddle novice C++ programmers. For instance, many frustrations with C++ arise from the language's focus on efficiency. A case in point is C++'s lack of a standard garbage collector, which can be inefficient in certain domains (such as real-time process control systems). However, knowledge of reference counting patterns (such as the "Counted Pointer" idiom [2,3]) can often serve the same role as an automatic garbage collector.
Another common frustration with C++ is the undefined (and thus non-portable) order in which constructors for global objects in separate compilation units are initialized. This is particularly problematic for applications built using dynamic link libraries. In this case, one solution is to apply an object creational pattern like Singleton, which ensures a class only has one instance and provides a global point of access to this instance . The Singleton pattern is often used to alleviate problems stemming from dependencies in the order in which globally accessible objects are initialized.
Capturing and documenting these types of memory management patterns is important for another reason -- it creates a body of literature that other C++ programmers can study and build upon to solve larger problems. For instance, in this issue, Ron White's feature article utilizes the Counted Pointer idiom to manage the low-level memory requirements of his "Unique Representation" pattern. Moreover, Ron's Unique Representation pattern also builds upon the Singleton pattern to ensure that there exists in memory only one copy of each unique object of a class.
Patrice Gautier's article on "Extending the Visitor Pattern" is another example of extending existing patterns to produce new and better ways of solving recurring problems in complex C++ programs. Patrice explains how the use of C++ templates can overcome some common traps and pitfalls with the form of the Visitor pattern described in .
Ironically, this month's "Pattern Hatching" column by John Vlissides also discusses the Visitor pattern. One of the themes in John's column is that design tradeoffs (such as time vs. space) often motivate the use of one group of patterns rather than another. John explains how the structural complexity of the Observer pattern (which is ubiquitous in C++ GUI frameworks like MFC and Interviews) can be alleviated by using the Visitor pattern, at the expense of some additional run-time overhead.
Dov Bulka's article on "Performance and C++: Separating Myth from Reality" focuses on another design tradeoff (flexibility vs. performance). His work focuses on C++ programming techniques for optimizing the efficiency of performance-sensitive software systems, in this case the communication subsystem in IBM's AIX operating system kernel.
Dov doesn't describe his techniques in a standard pattern form. However, his techniques certainly fit the definition of patterns since they are recurring solutions used to solve performance problems throughout the AIX communication subsystem. In the same vein, John Lakos' feature article on "Large-Scale C++ Software Design" focuses on effective techniques for structuring the physical hierarchy of software systems to improve testability, maintainability, and reuse. His work documents proven experience used at Mentor Graphics to build very large and complex CAD systems in C++.
The patterns covered in John's article address a more architectural level of abstraction than the other patterns in this issue, which focus more on C++ programming and design. Those of you interested in reading about patterns in other areas, such as organizational patterns, might check out Jim Coplien's chapter on "A Generative Development-Process Pattern Language" in the first Pattern Languages of Program Design book . The second volume  of this series of books just came out, and it has some excellent patterns related to C++, such as Tom Cargill's pattern on "Localized Ownership: Managing Dynamic Objects in C++."
This month's editors corner just barely scratches the surface of patterns and the patterns community. The Pattern Languages of Programming (PLoP) conference, which should be taking place as you read this issue in September, is an annual forum dedicated to improving the expression of patterns. In addition, there are workshops, tutorials, and papers on patterns at other object-oriented conferences (such as Object Expo, C++ World, OOPSLA, ECOOP, and COOTS).
Patterns succeed because you take the time to read, learn, use, and write them. I strongly encourage you to get involved in the patterns community. For starters, the World Wide Web URL http://st-www.cs.uiuc.edu/users/patterns contains a comprehensive on-line reference to pattern-related material.
2. Coplien, J. Advanced C++ Programming Styles and Idioms, Addison-Wesley, 1992.
3. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Pattern-Oriented Software Architecture - A System of Patterns. Wiley and Sons, 1996.
4. J. O. Coplien and D. C. Schmidt, eds., Pattern Languages of Program Design, Vol 1. Reading, MA: Addison-Wesley, 1995.
5. J. Vlissides, J. O. Coplien, and N. Kerth, eds., Pattern Languages of Program Design, Vol 2. Reading, MA: Addison-Wesley, 1996.
Back to C++ Report Editorials home page.