Table of Contents
Preface xiAcknowledgments xvIntroduction 1Chapter 1: Containers 11
Item 1: Choose your containers with care. 11
Item 2: Beware the illusion of container-independent code. 15
Item 3: Make copying cheap and correct for objects in containers. 20
Item 4: Call
empty instead of checking
size() against zero. 23
Item 5: Prefer range member functions to their single-element counterparts. 24
Item 6: Be alert for C++’s most vexing parse. 33
Item 7: When using containers of
newed pointers, remember to
delete the pointers before the container is destroyed. 36
Item 8: Never create containers of
auto_ptrs. 40
Item 9: Choose carefully among erasing options. 43
Item 10: Be aware of allocator conventions and restrictions. 48
Item 11: Understand the legitimate uses of custom allocators. 54
Item 12: Have realistic expectations about the thread safety of STL containers. 58
Chapter 2:
vector and
string 63
Item 13: Prefer
vector and
string to dynamically allocated arrays. 63
Item 14: Use
reserve to avoid unnecessary reallocations. 66
Item 15: Be aware of variations in
string implementations. 68
Item 16: Know how to pass
vector and
string data to legacy APIs. 74
Item 17: Use “the swap trick” to trim excess capacity. 77
Item 18: Avoid using
vector<bool>. 79
Chapter 3: Associative Containers 83
Item 19: Understand the difference between equality and equivalence. 83
Item 20: Specify comparison types for associative containers of pointers. 88
Item 21: Always have comparison functions return
false for equal values. 92
Item 22: Avoid in-place key modification in
set and
multiset. 95
Item 23: Consider replacing associative containers with sorted
vectors. 100
Item 24: Choose carefully between
map::operator[] and
map::insert when efficiency is important. 106
Item 25: Familiarize yourself with the nonstandard hashed containers. 111
Chapter 4: Iterators 116
Item 26: Prefer
iterator to
const_iterator,
reverse_iterator, and
const_reverse_iterator. 116
Item 27: Use
distance and
advance to convert
const_iterators to
iterators. 120
Item 28: Understand how to use a
reverse_iterator’s base
iterator. 123
Item 29: Consider
istreambuf_iterators for character by character input. 126
Chapter 5: Algorithms 128
Item 30: Make sure destination ranges are big enough. 129
Item 31: Know your sorting options. 133
Item 32: Follow
remove-like algorithms by
erase if you really want to remove something. 139
Item 33: Be wary of
remove-like algorithms on containers of pointers. 143
Item 34: Note which algorithms expect sorted ranges. 146
Item 35: Implement simple case-insensitive string comparisons via
mismatch or
lexicographical_compare. 150
Item 36: Understand the proper implementation of
copy_if. 154
Item 37: Use
accumulate or
for_each to summarize ranges. 156
Chapter 6: Functors, Functor Classes, Functions, etc. 162
Item 38: Design functor classes for pass-by-value. 162
Item 39: Make predicates pure functions. 166
Item 40: Make functor classes adaptable. 169
Item 41: Understand the reasons for
ptr_fun,
mem_fun, and
mem_fun_ref. 173
Item 42: Make sure
less<T> means
operator<. 177
Chapter 7: Programming with the STL 181
Item 43: Prefer algorithm calls to hand-written loops. 181
Item 44: Prefer member functions to algorithms with the same names. 190
Item 45: Distinguish among
count,
find,
binary_search,
lower_bound,
upper_bound, and
equal_range. 192
Item 46: Consider function objects instead of functions as algorithm parameters. 201
Item 47: Avoid producing write-only code. 206
Item 48: Always
#include the proper headers. 209
Item 49: Learn to decipher STL-related compiler diagnostics. 210
Item 50: Familiarize yourself with STL-related web sites. 217
Bibliography 225Appendix A: Locales and Case-Insensitive String Comparisons 229 Appendix B: Remarks on Microsoft’s STL Platforms 239Index 245
Forewords & Introductions
It came without ribbons!
It came without tags! It came without packages, boxes or bags!
-- Dr. Seuss, How the Grinch Stole Christmas!, Random House, 1957
I first wrote about the Standard Template Library in 1995, when I concluded the final Item of More Effective C++ with a brief STL overview. I should have known better. Shortly thereafter, I began receiving mail asking when I'd write Effective STL.
I resisted the idea for several years. At first, I wasn't familiar enough with the STL to offer advice on it, but as time went on and my experience with it grew, this concern gave way to other reservations. There was never any question that the library represented a breakthrough in efficient and extensible design, but when it came to using the STL, there were practical problems I couldn't overlook. Porting all but the simplest STL programs was a challenge, not only because library implementations varied, but also because template support in the underlying compilers ranged from good to awful. STL tutorials were hard to come by, so learning "the STL way of programming" was difficult, and once that hurdle was overcome, finding comprehensible and accurate reference documentation was equally difficult. Perhaps most daunting, even the smallest STL usage error often led to a blizzard of compiler diagnostics, each thousands of characters long, most referring to classes, functions, or templates not mentioned in the offending source code, almost all incomprehensible. Though I had great admiration for the STL and for the people behind it, I felt uncomfortable recommending it to practicing programmers. I wasn't sure it was possible to use the STL effectively.
Then I began to notice something that took me by surprise. Despite the portability problems, despite the dismal documentation, despite the compiler diagnostics resembling transmission line noise, many of my consulting clients were using the STL anyway. Furthermore, they weren't just playing with it, they were using it in production code! That was a revelation. I knew that the STL featured an elegant design, but any library where programmers are willing to endure portability headaches, poor documentation, and incomprehensible error messages has a lot more going for it than just good design. For an increasingly large number of professional programmers, I realized, even a bad implementation of the STL was preferable to no implementation at all.
Furthermore, I knew that the situation regarding the STL would only get better. Libraries and compilers would grow more conformant with the Standard (they have), better documentation would become available (it has -- check out the bibliography beginning on page 297), and compiler diagnostics would improve (for the most part, we're still waiting, but Item 49 offers suggestions for how to cope in the meantime). I therefore decided to chip in and do my part for the burgeoning STL movement, and this book is the result: 50 specific ways to improve your use of C++'s Standard Template Library.
My original plan was to write the book in the second half of 1999, and with that thought in mind, I put together an outline. But then I paused and changed course. I suspended work on the book, and I developed an introductory training course on the STL, which I then taught several times to different groups of programmers. About a year later, I returned to the book, significantly revising the outline based on my experiences with the training course. In the same way that my Effective C++ has been successful by being grounded in the problems faced by real programmers, it's my hope that Effective STL similarly addresses the practical aspects of STL programming -- the aspects most important to professional developers.
I am always on the lookout for ways to improve my understanding of C++. If you have suggestions for new guidelines for STL programming or if you have comments on the guidelines in this book, please let me know. In addition, it is my continuing goal to make this book as accurate as possible, so for each error in this book that is reported to me -- be it technical, grammatical, typographical, or otherwise -- I will, in future printings, gladly add to the acknowledgments the name of the first person to bring that error to my attention. Send your suggested guidelines, your comments, and your criticisms to estl@aristeia.com.
I maintain a list of changes to this book since its first printing, including bug-fixes, clarifications, and technical updates. The list is available at the Effective STL Errata web site,http://www.aristeia.com/BookErrata/estl1e-errata.html.
If you'd like to be notified when I make changes to this book, I encourage you to join my mailing list. I use the list to make announcements likely to be of interest to people who follow my work on C++. For details, consult http://www.aristeia.com/MailingList/.
SCOTT DOUGLAS MEYERS
STAFFORD, OREGON
http://www.aristeia.com/
APRIL 2001
Read an Excerpt
It came without ribbons!
It came without tags! It came without packages, boxes or bags!
— Dr. Seuss, How the Grinch Stole Christmas!, Random House, 1957
I first wrote about the Standard Template Library in 1995, when I concluded the final Item of More Effective C++ with a brief STL overview. I should have known better. Shortly thereafter, I began receiving mail asking when I’d write Effective STL.
I resisted the idea for several years. At first, I wasn’t familiar enough with the STL to offer advice on it, but as time went on and my experience with it grew, this concern gave way to other reservations. There was never any question that the library represented a breakthrough in efficient and extensible design, but when it came to using the STL, there were practical problems I couldn’t overlook. Porting all but the simplest STL programs was a challenge, not only because library implementations varied, but also because template support in the underlying compilers ranged from good to awful. STL tutorials were hard to come by, so learning “the STL way of programming” was difficult, and once that hurdle was overcome, finding comprehensible and accurate reference documentation was equally difficult. Perhaps most daunting, even the smallest STL usage error often led to a blizzard of compiler diagnostics, each thousands of characters long, most referring to classes, functions, or templates not mentioned in the offending source code, almost all incomprehensible. Though I had great admiration for the STL and for the people behind it, I felt uncomfortable recommending it to practicingprogrammers. I wasn’t sure it was possible to use the STL effectively.
Then I began to notice something that took me by surprise. Despite the portability problems, despite the dismal documentation, despite the compiler diagnostics resembling transmission line noise, many of my consulting clients were using the STL anyway. Furthermore, they weren’t just playing with it, they were using it in production code! That was a revelation. I knew that the STL featured an elegant design, but any library where programmers are willing to endure portability headaches, poor documentation, and incomprehensible error messages has a lot more going for it than just good design. For an increasingly large number of professional programmers, I realized, even a bad implementation of the STL was preferable to no implementation at all.
Furthermore, I knew that the situation regarding the STL would only get better. Libraries and compilers would grow more conformant with the Standard (they have), better documentation would become available (it has — check out the bibliography beginning on page 225), and compiler diagnostics would improve (for the most part, we’re still waiting, but Item 49 offers suggestions for how to cope while we wait). I therefore decided to chip in and do my part for the burgeoning STL movement, and this book is the result: 50 specific ways to improve your use of C++’s Standard Template Library.
My original plan was to write the book in the second half of 1999, and with that thought in mind, I put together an outline. But then I paused and changed course. I suspended work on the book, and I developed an introductory training course on the STL, which I then taught several times to different groups of programmers. About a year later, I returned to the book, significantly revising the outline based on my experiences with the training course. In the same way that my Effective C++ has been successful by being grounded in the problems faced by real programmers, it’s my hope that Effective STL similarly addresses the practical aspects of STL programming — the aspects most important to professional developers.
I am always on the lookout for ways to improve my understanding of C++. If you have suggestions for new guidelines for STL programming or if you have comments on the guidelines in this book, please let me know. In addition, it is my continuing goal to make this book as accurate as possible, so for each error in this book that is reported to me — be it technical, grammatical, typographical, or otherwise — I will, in future printings, gladly add to the acknowledgments the name of the first person to bring that error to my attention. Send your suggested guidelines, your comments, and your criticisms to estl@aristeia.com.
I maintain a list of changes to this book since its first printing, including bug-fixes, clarifications, and technical updates. The list is available at the Effective STL Errata web site, http://www.aristeia.com/BookErrata/estl1e-errata.html.
If you’d like to be notified when I make changes to this book, I encourage you to join my mailing list. I use the list to make announcements likely to be of interest to people who follow my work on C++. For details, consult http://www.aristeia.com/MailingList/.
Scott Douglas Meyers
Stafford, Oregon
April 2001
http://aristeia.com/
Loading...