Previous | Table of Contents | Next |
In addition to the iterators and algorithms, the library provides an assortment of adaptors, which can build containers and iterators out of other containers and iterators. For example, there is a reverse_iterator template that, given a bidirectional iterator, yields a new bidirectional iterator that accesses the same sequence as the original iterator but in the opposite direction. This template makes it unnecessary to have separate find first and find last operations; instead, one can find the last element in a sequence with a given property by find the first element in the sequence obtained by reversing the iterators. Other adaptors offer convenient ways of constructing function objects, which are object that act like functions.
All these details should not be allowed to obscure the most important aspects of the container library:
This strategy implies that if there are M containers and N algorithms, the total complexity of the library is M+N instead of M×N. In effect, the iterators provide an intellectual framework for designing and extending the library that may prove to be more important than the detailed design of the library itself.
C++ is neither the smallest nor the most elegant programming language around. Why, then, bother with C++ at all?
The main reason is that even if C++ is not the best possible language for every application, it is a single language that does a wide variety of things wellmore than well enough to be useful. It is possible to imagine building a system with one language for the low-level parts, another for the object-oriented parts, and still another to determine the overall structure, but C++ is a single language that can handle an entire system.
This ability to solve a wide range of problems did not arise by accident. Rather, it was the result of listening to actual users. C++ had an active, geographically dispersed user community remarkably early in its evolution. Many parts of C++ are the way they are because several different people, when using early versions, found that those versions lacked support for particular problems that they needed to solve. In that sense, the growth of C++ has been more organic than is common for programming languages.
This article has viewed C++ as comprising five major parts:
It would be a mistake to think that each of these parts of the language is suited only to particular kinds of problems. Rather, they offer the possibility of programming in a wide variety of styles, which, in turn, makes it possible to choose a style that is appropriate to the application.
The definitive work on C++ is, of course, Bjarne Stroustrups The C++ programming language (3rd edition, Addison-Wesley, 1997). It covers the entire language, and library, in enough detail that a more detailed reference will often be unnecessary.
If a more detailed reference does turn out to be necessary, the ISO Standard (expected in 1998) is the place to look. Although not always easy to understand, the Standard is the definition of C++.
People who want a more leisurely tutorial introduction to C++ may wish to try Stanley Lippmans and Josée Lajoie C++ Primer (Addison-Wesley, 1998). Lippman has also written a book called Inside the C++ object model (Addison-Wesley, 1996), which is intended for programmers who want to understand in detail how to implement the language at the machine level.
For a deeper understanding of why the language is the way it is, consider Stroustrups Design and evolution of C++ (Addison-Wesley, 1994). To learn more about how to solve problems in C++, read Ruminations on C++ by Andrew Koenig and Barbara E. Moo (Addison-Wesley, 1997). Marshall Cline offers a completely different way of understanding C++, by answering a wide variety of common questions in his C++ FAQs book (Addison-Wesley, 1995 ).
Finally, programmers who are building systems in C++ will want to understand the strategies described in Design patterns by Gamma, Helm, Johnson, and Vlissides (Addison-Wesley, 1995), and related programming techniques in Jim Copliens Advanced C++ styles and idioms (Addison-Wesley, 1992).
Aho, A. V., B. W. Kernighan, and P. J. Weinberger. 1988. The Awk programming language. Reading, MA: Addison-Wesley.
Koenig, A., and B. E. Moo. 1997. 1997. Ruminations on C++. Reading, MA: Addison-Wesley.
Thanks to Jeffrey Oldham and Bjarne Stroustrup for reviewing drafts of this article.
Previous | Table of Contents | Next |