Stl Tutorial & Reference Guide: C++ Programming With the Standard Template Library (Addison-Wesley Professional Computing Series) (Hardcover)

by David R. Musser (Author), Atul Saini (Author)

Editorial Reviews

Product Description
As part of the C++ standard, STL provides programmers with a catalog of reusable software components plus the rules that govern how to use them. This guide is the sole source for comprehensive tutorial and reference material on this new technology. Co-authored by one of the chief developers of the standard, this book teaches you everything you need to know about using STL effectively.

From the Inside Flap
In 1968 Doug McIlroy presented his famous paper, "Mass Produced Software Components" (Ref. 6). Now, more than a quarter of a century later, we still have not fully realized his vision of standard libraries of reusable components (which today are also known as "software building blocks" or "software ICs"). In some areas such as numerical and statistical computation, there is a long tradition of heavy use of standard libraries, rather than writing source code entirely from scratch, but in many other areas, standardization hasn't occurred. Even in the area of fundamental data structures and data-processing algorithms, where there is perhaps the greatest potential benefit from component standardization and widespread component use, no set of components has emerged and been embraced by large numbers of programmers or software development managers.

In the absence of a standard set of such data structure and algorithm components, programmers have been forced either to program everything from scratch or to adopt one of several commercial packages. While writing everything from scratch often gives programmers a sense of control, it is also a source of frustration, since there is rarely time to implement the best techniques, even assuming they are already known to the programmer. And the available commercial libraries have suffered from several drawbacks. In the C++ realm, for example, the problems include

Incompatibility: The interfaces of classes supplied by various vendors are invariably different, making it difficult to write portable code.

Inefficiency: The implementations of most commercially available components libraries typically involve complex class hierarchies with extensive use of inheritance and virtual functions. As a result, using these components results in significantly less-efficient programs than could be written in C.

Unwieldy interfaces: In most component libraries, all operations to be performed on a data structure are part of the interface of the class defining it. Besides making it difficult for programmers to add new operations without recompiling the code, this makes the interfaces needlessly large.

These problems have been widely recognized for many years, but few solutions have been proposed and none has been widely embraced - not, that is, until now. The Standard Template Library is both a remarkable advance in programming methodology and a fully accepted part of the C++ Standard Library. It does not seem overly optimistic to expect that STL components will become some of the most widely used software in existence. The reasons are fivefold:

C++ is becoming one of the most widely used programming languages (which is in large part due to the support it provides for building and using component libraries).

Since STL has been incorporated into the ANSI/ISO standard for C++ and its libraries, compiler vendors are making it part of their standard distributions.

All components in STL are generic, meaning that they are adaptable (by language-supported, compile-time techniques) to many different uses.

The generality of STL components has been achieved without sacrificing efficiency.

The design of STL components as fine-grained, interchangeable building blocks makes them a suitable basis for further development of components for specialized areas such as databases, user interfaces, and so forth.

Virtually all C++ programmers know that the origin of this language is due to one person, Bjarne Stroustrup, who began thinking of how to extend the C language to support definition of classes and objects as early as 1979. So too it is the case that the architecture of STL is largely the creation of one person, Alexander Stepanov.

It is interesting that it was also in 1979, at about the same time as Stroustrup's initial research, that Alex began working out his initial ideas of generic programming and exploring their potential for revolutionizing software development. Although one of this book's authors (D.R.M.) had developed and advocated some aspects of generic programming as early as 1971, it was limited to a rather specialized area of software development (computer algebra). It was Alex who recognized the full potential for generic programming and persuaded his then-colleagues at General Electric Research and Development (including, primarily, D.R.M. and Deepak Kapur) that generic programming should be pursued as a comprehensive basis for software development. But at that time there was no real support in any programming language for generic programming. The first major language to provide such support was Ada, and by 1987 Alex and D.R.M. had developed and published an Ada library for list processing that embodied the results of much of their research on generic programming. However, Ada had not achieved much acceptance outside of the defense industry, and C++ seemed like a better bet for both becoming widely used and providing good support for generic programming, even though the language was relatively immature (it did not even have templates, which were added only later). Another reason for turning to C++, which Alex recognized early on, was that the C/C++ model of computation, which allows very flexible access to storage (via pointers) is crucial to achieving generality without losing efficiency.

Still, much research and experimentation were needed, not just to develop individual components, but more importantly to develop an overall architecture for a component library based on generic programming. First at AT&T Bell Laboratories and later at Hewlett-Packard Research Labs, Alex experimented with many architectural and algorithm formulations, first in C and later in C++. D.R.M. collaborated in this research, and in 1992 Meng Lee joined Alex's project at HP and became a major contributor.

This work likely would have continued for some time just as a research project, or at best would have resulted in an HP-proprietary library, if Andrew Koenig of Bell Labs had not become aware of the work and asked Alex to present the main ideas at a November 1993 meeting of the ANSI/ISO committee for C++ standardization. The committee's response was overwhelmingly favorable and led to a request from Koenig for a formal proposal in time for the March 1994 meeting. Despite the tremendous time-pressure, Alex and Meng were able to produce a draft proposal that received preliminary approval at that meeting.

The committee had several requests for changes and extensions (some of them major), and a small group of committee members met with Alex and Meng to help work out the details. The requirements for the most significant extension (associative containers) had to be shown to be consistent by fully implementing them, a task Alex delegated to D.R.M. It would have been quite easy for the whole enterprise to spin out of control at this point, but again Alex and Meng met the challenge and produced a proposal that received final approval at the July 1994 ANSI/ISO committee meeting. (Additional details of this history can be found in an interview Alex gave in the March 1995 issue of Dr. Dobbs Journal.)

Subsequently, the Stepanov and Lee document (Ref. 10) has been incorporated almost intact into the ANSI/ISO C++ draft standard (Ref. 1, parts of clauses 17 through 27). It also has influenced other parts of the C++ Standard Library, such as the string facilities, and some of the previously adopted standards in those areas have been revised accordingly.

In spite of STL's success with the committee, there remained the question of how STL would make its way into actual availability and use. With the STL requirements part of the publicly available draft standard, compiler vendors and independent software library vendors could of course develop their own implementations and market them as separate products or as selling points for their other wares. One of this book's authors (A.S.) was among the first to recognize the commercial potential and began exploring it as a line of business for his company, Modena Software Incorporated, even before STL had been fully accepted by the committee.

The prospects for early widespread dissemination of STL were considerably improved with Hewlett-Packard's decision to make its implementation freely available on the Internet in August 1994. This implementation, developed by Stepanov, Lee, and D.R.M. during the standardization process, is the basis of Modena's STL++ product and several other vendors' offerings; it is referred to in this book as the "HP reference implementation."

The Stepanov and Lee document, while precise and complete, was aimed more at the committee than at the wide audience of C++ programmers. Along with modifying the HP reference implementation to work well with several compilers and providing several additional classes, Modena developed the STL++ Manual, the first comprehensive user-level documentation of STL. (D.R.M. served as an advisor to Modena and was the principal author of the Tutorial section of the STL++ Manual.) We recognized, though, that an even more comprehensive treatment of STL was needed, one that would have better and more complete coverage of all aspects of the library. With much encouragement and assistance from our editor, Mike Hendrickson, we have attempted to meet this goal with the present book.

With the publication of this book, Modena and Addison-Wesley are also making available on the Internet all of the source code for examples used in this book, so that readers who want to try them do not have to type them. Instructions for finding and retrieving all of this material can be found in Appendix B.

We do not want to give the impression that we believe STL is the solution to all programming problems. There are potentially still some bumps in the road to its acceptance by the broad programming community, such as compiler weaknesses and the usual opportunities for misunderstanding of a radically new approach. We hope this book will make the road for STL itself as smooth as possible, but of course there are still many fundamental data structures and algorithms that are not covered. Beyond this realm, there are many more specialized areas of computation that also cry out for component standardization. References 3 and 7 discuss the larger view in some detail. We hope that among our readers will be some who have the vision and resources to continue in the direction that STL has opened up, carrying on its ideas to other component libraries, not only in C++ but also in other programming languages.

Although in the larger scheme of things it is just a small step toward realizing McIlroy's original vision (Ref. 6), STL is a remarkable achievement and has the potential for revolutionizing the way a large number of people program. We hope this book helps you become a full participant in that revolution.

We gratefully acknowledge the encouragement and assistance of many people. First and foremost, Alex Stepanov and Meng Lee offered continuous encouragement and were always available to help straighten out any misconceptions we had about the design of the library. Invaluable assistance with code development and testing was provided by several Modena staff members, including Atul Gupta, Kolachala Kalyan, and Narasimhan Rampalli. Several reviewers of earlier drafts gave us much valuable feedback and helped us find ways to present the most crucial ideas more clearly. They include Mike Ballantyne, Tom Cargill, Edgar Chrisostomo, Brian Kernighan, Scott Meyers, Larry Podmolik, Kathy Stark, Steve Vinoski, and John Vlissides. Others who also made valuable suggestions include Dan Benanav, Bob Cook, Bob Ingalls, Nathan Schimke, Kedar Tupil, and Rick Wilhelm. Finally, we thank the team at Addison-Wesley for their expert editorial and production assistance: Kim Dawley, Katie Duffy, Rosa Gonzalez, Mike Hendrickson, Simone Payment, Avanda Peters, John Wait, and Pamela Yee.

D.R.M.
Troy, NY

A.S.
Los Gatos, CA

October 1995

0201633981P04062001

See all Editorial Reviews

Product Details

• Hardcover: 400 pages
• Publisher: Addison-Wesley Pub (Sd) (March 1996)
• Language: English
• ISBN-10: 0201633981
• ISBN-13: 978-0201633986
• Product Dimensions: 8.9 x 7.6 x 1.2 inches
• Shipping Weight: 2 pounds
• Average Customer Review: 3.2 out of 5 stars See all reviews (25 customer reviews)
• Amazon.com Sales Rank: #1,354,729 in Books (See Bestsellers in Books)

  Popular in this category: (What's this?)

  #96 in

  Books > Computers & Internet > Programming > C > Language

Customer Reviews

Most Helpful Customer Reviews

18 of 18 people found the following review helpful:

2.0 out of 5 stars There's better out there, November 2, 1999

By A Customer

The book itself isn't that bad. It is a good high level tutorial without too much detail. However, if you want a tutorial and reference that is more up to date I'd recommend checking out The C++ Standard Library: A Tutorial and Reference. It was recently published and covers a broader scope (the whole standard library, not just the STL).

30 of 33 people found the following review helpful:

5.0 out of 5 stars incorrect reviews, November 3, 2000

By	John Richetta (WA, USA) - See all my reviews (REAL NAME)

Just a few more points, to refute earlier incorrect reviews:

One reviewer said: "For instance, in the detailed presentation of sets and multisets, nowhere is it mentioned what the difference between the two is. You have to go to the "Overview of STL components" to get the information."

This is incorrect: the authors cover the difference numerous places (and most people can guess what the difference is). See for example pages 118 and 151 (the latter being the section explaining set, multiset, and map).

Another reviewer said: "...it fails to mention several large chunks of STL that you could immediately use, including the functionals and some very useful pieces (strings (with iostreams), bit sets, fstreams, locales, limits, etc)."

This also is incorrect and misleading. Most of the items above are not part of STL, but rather the standard C++ library, so of course the authors don't discuss them. Also, presumably by "functionals" the reviewer means function objects, or function adaptors. Both of these are well coevered in the book.

Another review stated: "If you look for some concrete examples then this book isn't it."

This is hard to accept: almost every page of this book contains carefully chosen example code illustrating the point at hand. Even a little imagination should suffice to adapt it to your particulars.

And finally: "While this book might help you use STL containers in straightforward circumstances, it doesn't contain enough theory to give you mastery of the topic."

Also hard to accept. This book covers as much theory as there is to present; there aren't any higher level ideas than those presented here. For example, they take great pains to explain why there is a separation of algorithm and data structure, and to illustrate the pivotal role iterators play in organizing the library, to ensure (mostly) that the right algorithms are used with the right containers. If one looks for even deeper meaning, well, most of us don't know any, so feel free to write a book on it when you find it.

Seems like people are really biased against this book. Again, it's a really good introduction to the fundamentals. Sorry to see it get trashed.

28 of 31 people found the following review helpful:

4.0 out of 5 stars Useful, but not Handy, November 24, 2001

By	Mike Blaszczak (Mercer Island, WA, USA) - See all my reviews (REAL NAME)

John's reviews are interesting. While I agree with many of the points he makes, I disagree with some. And I found a few to be self-contradictory.

He says, for instance, that "This is a good solid book that will get you up to speed quickly on all the important ideas in STL, and many of its basic usage idioms", but then naievely claims that "there aren't any higher level ideas than those presented here". Does the book cover only basic concepts, or is it that if the book doesn't cover it, it is not knowledge?

The book is full of concrete examples. But my problem was that they were trivial. Reversing or sorting or finding characters within a string is great fun. But it doesn't help me understand who owns the memory within a container. Or how to directly and safely reference an element at an arbitrary position within a container outside of an iteration loop. A majority of the examples use trivial intrinsic datatypes for contained elements; how is using a struct or class different?

All of those issues are important aspects of using the library, and not something I think a busy reader should leave to "a little imagination". While most of the disputed facts are eventually available in the text, they're not easy to find. The organization of the book isn't quite intuitive enough to make it a thoughtful reference or a breezy tutorial.

And, in many cases, once found, they're not clear. John cited page 151 for an explanation of the differences between some of the collections. There, it says "With maps an multimaps, the data items are pairs of keys and data of some other type..." What's that mean? Two keys and data of some other type? Or a key and data of some other type? Does "pairs" mean "two", or an instance of the "pairs" utility class?

The book really is missing information. None of the examples do any error checking whatsoever, and the exceptions that the templates throw aren't described. (Maybe, like priority queues, error handling was formalized after the book went to press. It is showing its age, and there's now a 2nd edition. I haven't purchased it.)

It's ambitious to write a book that tries to serve as both a tutorial and the reference. (Me, I think it's just impossible.) This book does very well, but falls short of adequately completing either goal.

I think that there's a bias against this book because it doesn't fit well with the way these reviewers would have liked to learn the subject at hand. I know that's where I landed. While true masters do indeed make it look simple, making it look simple doesn't help learning. Otherwise, we could all watch Tiger Woods for a few Sundays before taking home a Buick and a six-figure check.