STL高效编程（英文影印版）[按需印刷]

.item 15: be aware of variations in string implementations.
item 16: know how to pass vector and string data to legacy apis.
item 17: use “the swap trick” to trim excess capacity.
item 18: avoid using vector[bool].
chapter 3: associative containers
item 19: understand the difference between equality and equivalence.
item 20: specify comparison types for associative containers of pointers.
item 21: always have comparison functions return false for equal values.
item 22: avoid in-place key modification in set and multiset.
item 23: consider replacing associative containers with sorted vectors.
item 24: choose carefully between map::operator[] and map::insert when efficiency is important.
item 25: familiarize yourself with the nonstandard hashed containers.
chapter 4: iterators
item 26: prefer iterator to const_iterator, reverse_iterator, and const_reverse_iterator.
item 27: use distance and advance to convert const_iterators to iterators.
item 28: understand how to use a reverse_iterator’s base iterator.
item 29: consider istreambuf_iterators for character by character input.
chapter 5: algorithms
item 30: make sure destination ranges are big enough.
item 31: know your sorting options.
item 32: follow remove-like algorithms by erase if you really want to remove something.
item 33: be wary of remove-like algorithms on containers of pointers.
item 34: note which algorithms expect sorted ranges.
item 35: implement simple case-insensitive string comparisons via mismatch or lexicographical_compare.
item 36: understand the proper implementation of copy_if.
item 37: use accumulate or for_each to summarize ranges.
chapter 6: functors, functor classes, functions, etc.
item 38: design functor classes for pass-by-value.
item 39: make predicates pure functions.
item 40: make functor classes adaptable.
item 41: understand the reasons for ptr_fun, mem_fun, and mem_fun_ref.
item 42: make sure less[t] means operator[.
chapter 7: programming with the stl
item 43: prefer algorithm calls to hand-written loops.
item 44: prefer member functions to algorithms with the same names.
item 45: distinguish among count, find, binary_search, lower_bound, upper_bound, and equal_range.
item 46: consider function objects instead of functions as algorithm parameters.
item 47: avoid producing write-only code.
item 48: always #include the proper headers.
item 49: learn to decipher stl-related compiler diagnostics.
item 50: familiarize yourself with stl-related web sites.
bibliography
appendix a: locales and case-insensitive string comparisons
appendix b: remarks on microsoft’s stl platforms
index

.　　SCOTT DOUGLAS MEYERS STAFFORD, OREGON
　　http://www.aristeia.com/ APRIL 2001
　　I had an enormous amount of help during the roughly two years it took me to make some sense of the STL, create a training course on it, and write this book. Of all my sources of assistance, two were particularly important. The first is Mark Rodgers. Mark generously volunteered to review my training materials as I created them, and I learned more about the STL from him than from anybody else. He also acted as a technical reviewer for this book, again providing observations and insights that improved virtually every Item.
　　The other outstanding source of:information was several C++-related Usenet newsgroups, especially compJang.c++.moderated ("clcm"), comp.std.c++, and microsoft, public.vc.stl. For well over a decade, I've depended on the participants in newsgroups like these to answer my questions and challenge my thinking, and it's difficult to imagine what I'd do without them. I am deeply grateful to the Usenet community for their help with both this book and my prior publications on C++.
　　My understanding of the STL was shaped by a variety of publications, the most important of which are listed in the Bibliography. I leaned especially heavily on Josuttis' The C++ Standard Library [3].
　　This book is fundamentally a summary of insights and observations made by others, though a few of the ideas are my own. I've tried to keep track of where I learned what, but the task is hopeless, because a typical Item contains information garnered from many sources over a long period of time. What follows is incomplete, but it's the best I can do. Please note that my goal here is to summarize where I first learned of an idea or technique, not where the idea or technique was originally developed or who came up with it.
　　In Item 1, my observation that node-based containers offer better support for transactional semantics is based on section 5.11.2 of Josuttis' The C++ Standard Library [3]. Item 2 includes an example from Mark Rodgers on how typedefs help when allocator types are changed. ..
　　Item 5 was motivated by Reeves' C++ Report column, "STL Gotchas" [17]. Item 8 sprang from Item 37 in Sutter's Exceptional C++ [8], and Kevlin Henney provided important details on how contalners of auto_ptrs fail in practice. In Usenet postings, Matt Austern provided examples of when allocators are useful, and I include his examples in Item 11. Item 12 is based on the discussion of thread safety at the SGI STL web site [21]. The material in Item 13 on the performance implications of reference counting in a multithreaded environment is drawn from Sutter's writings on this topic [20]. The idea for Item 15 came from Reeves' C++ Report column, "Using Standard string in the Real World, Part 2," [18]. In Item 16, Mark Rodgers came up with the technique I show for having a C API write data directly into a vector. Item 17 includes information from Usenet postings by Siemel Naran and Carl Barron. I stole Item 18 from Sutter's C++ Report column, "When Is a Container Not a Container?." [12]. In Item 20, Mark Rodgers contributed the idea of transforming a pointer into an object via a dereferencing functor, and Scott Lewandowski came up with the version of DereferenceLess I present. Item 21 originated in a Doug Harrison posting to microsoft.public.vc.stl, but the decision to restrict the focus of that Item to equality was mine. I based Item 22 on Sutter's C++ Report column, "Standard Library News: sets and maps" [13]; Matt Austern helped me understand the status of the Standardization Committee's Library Issue #103. Item 23 was inspired by Austern's C++ Report article, "Why You Shouldn't Use set -- and What to Use Instead" [15]: David Smallberg provided a neat refinement for my implementation of DataCompare. My description of Dinkumware's hashed containers is based on Plauger's C/C++ Users Journal column, "Hash Tables" [16]. Mark Rodgers doesn't agree with the overall advice of Item 26, but an early motivation for that Item was his observation that some container member functions accept only arguments- of type iterator. My treatment of Item 29 was motivated and informed by Usenet discussions involving Matt Austern and James Kanze; I was also influenced by Kreft and Langer's C++ Report article, "A Sophisticated Implementation of User-De~med Inserters and Extractors" [25].
　　Item 30 is due to a discussion in section 5.4.2 of Josuttis' The C++ Standard Library [3]. In Item 3 l, Marco Dalla Gasperina contributed the example use of nth_element to calculate medians, and use of that algorithm for finding percentiles comes straight out of section 18.7.1 of Stroustrup's The C++ Programming Language [7]. Item 32 was influenced by the material in section 5.6.1 of Josuttis' The C++ Standard Library [3]. Item 35 originated in Austern's C++ Report column "How to Do Case-Insensitive String Comparison" [11], and James Kanze's and John Potter's dcm postings helped me refine my understanding of the issues involved. Stroustrup's implementation for copy_if, which I show in Item 36, is from section 18.6.1 of his The C++ Programming Language [7]. Item 39 was largely motivated by the publications of Josuttis, who has written about "stateful predicates" in his The C++ Standard Library [3], in Standard Library Issue #92, and in his C++ Report article, "Predicates vs. Function Objects" [14]. In my treatment, I use his example and recommend a solution he has proposed, though the use of the term "pure function" is my own. Matt Austern confirmed my suspicion in Item 41 about the history of the terms memfun and mem_fun_ref. Item 42 can be traced to a lecture I got from Mark Rodgers when I considered violating that guideline. Mark Rodgers is also responsible for the insight in Item 44 that non-mem-ber searches over maps and multimaps examine both components of each pair, while member searches examine only the first (key) component. Item 45 contains information from various dcm contributors, including John Potter, Marcin Kasperski, Pete Becker, Dennis Yelle, and David Abrahams. David Smallberg alerted me to the utility of equal_range in performing equivalence-based searches and counts over sorted sequence containers. Andrei Alexandrescu helped me understand the conditions under which "the reference-to-reference problem" I describe in Item 50 arises, and I modeled my example of the problem on a similar example provided by Mark Rodgers at the Boost Web Site [22].
　　Credit for the material in Appendix A goes to Matt Austern, of course. I'm grateful that he not only gave me permission to include it in this book, he also tweaked it to make it even better than the original.
　　Good technical books require a thorough pre-publication vetting, and I was fortunate to benefit from the insights of an unusually talented group of technical reviewers. Brian Kernighan and Cliff Green offered early comments on a partial draft, and complete versions of the manuscript were scrutinized by Doug Harrison, Brian Kernighan, Tim Johnson, Francis Glassborow, Andrei Alexandrescu, David Smallberg, Aaron Campbell, Jared Manning, Herb Sutter, Stephen Dewhurst, Matt Austern, Gillmer Derge, Aaron Moore, Thomas Becker, Victor Von, and, of course, Mark Rodgers. Katrina Avery did the copyediting. One of the most challenging parts of preparing a book is finding good technical reviewers. I thank John Potter for introducing me to Jared Manning and Aaron Campbell.
　　Herb Sutter kindly agreed to act as my surrogate in compiling, running, and reporting on the behavior of some STL test programs under a beta version of Microsoft's Visual Studio .NET, while Leor Zolman undertook the herculean task of testing all the code in this book. Any errors that remain are my fault, of course, not Herb's or Leor's.
　　Angelika Langer opened my eyes to the indeterminate status of some aspects of STL function objects. This book has less to say about function objects than it otherwise might, but what it does say is more likely to remain true. At least I hope it is.
　　This printing of the book is better than earlier printingS, because I was able to address problems identified by the following sharp-eyed readers: Jon Webb, Michael Hawkins, Derek Price, Jim Scheller, Carl Manaster, Herb Sutter, Albert Franklin, George King, Dave Miller, Harold Howe, John Fuller, Tim McCarthy, John Hershberger, Igor Mikolic-Torreira, Stephan Bergmann, Robert Allan Schwartz, dohn Potter, David Grigsby, Sanjay Pattni, Jesper Andersen, Jing Tao Wang, Andre Blavier, Dan Schmidt, Bradley White, Adam Petersen, Wayne Goertel, Gabriel Netterdag, Jason Kenny, Scott Blachowicz, Seyed H. Haeri, Gareth McCaughan, Giulio Agostini, Fraser Ross, Wolfram Burkhardt, Keith Stanley, Leor Zolman, Chan Ki Lok, Motti Abramsky, Kevlin Henney, Stefan Kuhlins, Phillip Ngan, Jim Phillips, Ruediger Dreier, Guru Chandar, Charles Brockman, Day Barr, Eric Niebler, Sharad Kala, Declan Moran, Nick de Smith, David Callaway, Shlomi Frank, Andrea Grfffmi, Hans Eckardt, David Smallberg, Matt Page, and Andy Fyfe. I'm grateful for their help in improving Effective STL.
　　My collaborators at Addison-Wesley included John Wait (my editor and now a senior VP), Alicia Carey and Susannah Buzard (his assistants n and n+l), John Fuller (the production coordinator), Karin Hansen (the cover designer), Jason Jones (all-around technical guru, especially with respect to the demonic software spewed forth by Adobe), Marty Rabinowitz (their boss, but he works, too), and Curt Johnson, Chanda Leary-Coutu, and Robin Bruce (all marketing people, but still very nice).
　　Abbi Staley made Sunday lunches a routinely pleasurable experience. As she has for the six books and one CD that came before it, my wife, Nancy, tolerated the demands of my research and writing with her usual forbearance and offered me encouragement and support when I needed it most. She never fails to remind me that there's more to life than C++ and software.
　　And then there's our dog, Persephone. As I write this, it is her sixth birthday. Tonight, she and Nancy and I will visit Baskin-Robbins for ice cream. Persephone will have vanfila. One scoop. In a cup. To go. ...