C++STL(Standard Template Library,标准模板库)是一次革命,但是学习如何使用它却是一个挑战。在本书中,Scott Meyers(两本最畅销的书《Effective C++》和《More Effective C++》的作者)提示了专家总结的一些关键规则,以便最大限度的使用标准模板库。\r\n 其他书只是描述了STL中有什么,而本书则讲述了如何使用STL。本书共有50条原则,对于每一条原则,Scott Meyers都通过透彻的分析和经典的实例来进行讲解,从而使读者不仅可以了解要做什么,而且还能够了解何时做以及为何做。\r\n 像Meyers的其他著作一样,这本书充满了从实践中总结出来的智慧。它清晰、简明、透彻的风格必将使每位STL程序员受益匪浅。
Preface. \r\nAcknowledgments. \r\nIntroduction. \r\n\r\n1. Containers. \r\n\r\nItem 1: Choose your containers with care. \r\nItem 2: Beware the illusion of container-independent code. \r\nItem 3: Make copying cheap and correct for objects in containers. \r\nItem 4: Call empty instead of checking size against zero. \r\nItem 5: Prefer range member functions to their single-element counterparts. \r\nItem 6: Be alert for C++'s most vexing parse. \r\nItem 7: When using containers of newed pointers, remember to delete the pointers before the container is destroyed. \r\nItem 8: Never create containers of auto_ptrs. \r\nItem 9: Choose carefully among erasing options. \r\nItem 10: Be aware of allocator conventions and restrictions. \r\nItem 11: Understand the legitimate uses of custom allocators. \r\nItem 12: Have realistic expectations about the thread safety of STL containers. \r\n\r\n\r\n2. Vector and string. \r\n\r\nItem 13: Prefer vector and string to dynamically allocated arrays. \r\nItem 14: Use reserve to avoid unnecessary reallocations. \r\nItem 15: Be aware of variations in string implementations. \r\nItem 16: Know how to pass vector and string data to legacy APIs. \r\nItem 17: Use "the swap trick" to trim excess capacity. \r\nItem 18: Avoid using vector. \r\n\r\n\r\n3. Associative Containers. \r\n\r\nItem 19: Understand the difference between equality and equivalence. \r\nItem 20: Specify comparison types for associative containers of pointers. \r\nItem 21: Always have comparison functions return false for equal values. \r\nItem 22: Avoid in-place key modification in set and multiset. \r\nItem 23: Consider replacing associative containers with sorted vectors. \r\nItem 24: Prefer map::insert to map::operator when efficiency is a concern. \r\nItem 25: Familiarize yourself with the nonstandard hashed containers. \r\n\r\n\r\n4. Iterators. \r\n\r\nItem 26: Prefer iterator to const_iterator, reverse_iterator, and const_reverse_iterator. \r\nItem 27: Use distance and advance to convert const_iterators to iterators. \r\nItem 28: Understand how to use a reverse_iterator's base iterator. \r\nItem 29: Consider istreambuf_iterators for character by character input. \r\n\r\n\r\n5. Algorithms. \r\n\r\nItem 30: Make sure destination ranges are big enough. \r\nItem 31: Know your sorting options. \r\nItem 32: Follow remove-like algorithms by erase if you really want to remove something. \r\nItem 33: Be wary of remove-like algorithms on containers of pointers. \r\nItem 34: Note which algorithms expect sorted ranges. \r\nItem 35: Implement simple case-insensitive string comparisons via mismatch or lexicographical_compare. \r\nItem 36: Use not1 and remove_copy_if to perform a copy_if. \r\nItem 37: Use accumulate or for_each to summarize sequences. \r\n\r\n\r\n6. Functors, Functor Classes, Functions, etc. \r\n\r\nItem 38: Design functor classes for pass-by-value. \r\nItem 39: Make predicates pure functions. \r\nItem 40: Make functor classes adaptable. \r\nItem 41: Understand the reasons for ptr_fun, mem_fun, and mem_fun_ref. \r\nItem 42: Make sure less means operator<. \r\n\r\n\r\n7. Programming with the STL. \r\n\r\nItem 43: Prefer algorithm calls to hand-written loops. \r\nItem 44: Prefer member functions to algorithms with the same names. \r\nItem 45: Distinguish among count, find, binary_search, lower_bound, upper_bound, and equal_range. \r\nItem 46: Consider function objects instead of functions as algorithm parameters. \r\nItem 47: Avoid producing write-only code. \r\nItem 48: Always #include the proper headers. \r\nItem 49: Learn to decipher STL-related compiler diagnostics. \r\nItem 50: Familiarize yourself with STL-related web sites\r\n\r\nBibliography\r\n\r\nAppendix A:Locales and Case-Insensitive String Comparisons\r\n\r\nAppendix B:Remarks on Microsoft's STL Platforms\r\n\r\nIndex
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 thesimplest 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 a challenge. 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 ST[, 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. Furthet,nore, 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 for which programmers are willing to endure portability headaches, poor documentation, and incomprehensible error mes sages 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 -- consult 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 STL movement. 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 changed course. I suspended work on the book and developed an introductory training course on the STL, which I then taught several times to 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 ff 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 amiling 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/.