The following changes were made for the eighth printing of the book. These changes apply to your copy of Effective STL only if it's one of the first seven printings.

    DATE                                                                  DATE
  REPORTED WHO PAGES  WHAT                                                FIXED
  -------- --- -----  ------------------------------------------------  --------
   6/ 7/06 sdm    47  Footnote symbol should immediately follow          6/ 7/06
                 121  punctuation, not precede it.
 
  12/28/05 vxs    61  In footnote, "ma y" ==> "may".  (I have no         6/ 7/06
                      idea why the FrameMaker spell checker does not 
                      catch this.  I ran it, trust me.)

   5/ 2/06 rxp 72-73  The bottom part of pg. 72 says that                6/ 7/06
                      Implementation C reserves no space for a trailing
                      null, but the bottom part of pg. 75 implies that
                      I know of no contemporary library implementation
                      where a trailing null is not stored (which is
                      true).  Unfortunately, I am unable to reproduce
                      the results for Implementation C described on
                      pg. 72, so I removed mention of Implementation C
                      from the bottom of page 72 (which caused a change
                      in the break between pages 72 and 73).

   4/17/06 txs   131  Unlike front_inserter and back_inserter (which     6/ 7/06
                      always call push_front and push_back,
                      respectively), inserter returns an iterator that
                      keeps track of where to perform its next
                      insertion.  I added a footnote to this effect.

   1/ 2/06 vxs   152  In line 7 of final para, "return false" ==>        6/ 7/06
                      "returns false".

   3/28/06 cmm   190  Last word on page:  "is" ==> "are".                6/ 7/06

   1/ 7/06 mxd   205  Per the resolution of core language issue 115,     6/ 7/06
                      the line of code at the top of this page is now 
                      valid.  I added a footnote to this effect.

The following changes were made for the tenth printing of the book. These changes apply to your copy of Effective STL only if it's printing 7, 8, or 9.

    DATE                                                                  DATE
  REPORTED WHO PAGES  WHAT                                                FIXED
  -------- --- -----  ------------------------------------------------  --------
   3/14/07 cxb    68  In the 9th printing only, in code at top of page,    NA
                      the following line of red code is missing between 
                      the two black lines:
                        v.reserve(1000);
                      (This was an error introduced during printing.
                      The book source itself is correct, hence the lack
                      of a fix date.)

   9/27/06 gxu   100  Point 3 from the bottom of page 99 is repeated    10/ 4/05
                      at the top of page 100.  (This error was 
                      introduced in the 7th printing, when I modified 
                      pages 99 and 100 but sent the printer only the 
                      new page 99, sigh.)

The following changes have been proposed but have not yet been published:

    DATE                                                                  DATE
  REPORTED WHO PAGES  WHAT                                                FIXED
  -------- --- -----  ------------------------------------------------  --------
   1/13/07 nxd Item 44 This Item also applies to the swap algorithm.  (I
                      think it's unfortunate that swap is considered an
                      algorithm, but it is.  More details are available
                      in the newsgroup discussion on this topic.)

  11/27/07 cpj    81  Another alternative to vector<bool> is
                      basic_string<bool>.

  12/22/07 nxd    81  Other alternatives to vector<bool> include
                      vector<unsigned char> and Boost's 
                      dynamic_bitset. 

   8/20/07 abt   100  The last sentence in step 5 at the top of the 
                      page is not quite correct.  As shown in the code, 
                      the iterator passed to insert is not the one from
                      step 1, it's a copy of that iterator that has
                      been incremented.

   9/15/07 dmr   145  In 3rd para, "containers of dynamically allocated
                      pointers" ==> "containers of pointers to
                      dynamically allocated objects".

   1/24/08 sdm   225  In the second bullet entry, reformat "Second       1/25/08
                      Edition" to match how all other edition 
                      references are formatted.

   1/24/08 sdm   226  Revise [5] to refer to the 2003 edition and        1/25/08
                      avoid mentioning the price.  (It's now $30).

   2/ 4/08 sdm   226  Revise [4] to refer to [21] instead of 
                      giving URL?

   1/15/08 mxs 227-228 For [19], replace the URL with                    1/25/08
                      http://erdani.org/publications/traits.html. 
                      For the second bullet entry after [27], replace
                      the URL with  http://www.ddj.com/cpp/184401382.
                      For [29], replace the URL with 
                      http://www.aristeia.com/BookErrata/auto_ptr-update.html.

   3/11/08 sdm   228  Remove question mark from end of article title
                      in second bullet entry after [27].

   3/11/08 sdm   228  URL for bullet entry above [28] should be
                      http://www.aristeia.com/BookErrata/ec++3e-errata.html.

What follows are interesting comments about the material in Effective STL, but I don't expect to be able to modify the book to take these comments into account until (if ever) I write a second edition.

  DATE
REPORTED WHO PAGES  WHAT
-------- --- -----  -----------------------------------------------------------
 6/22/01 lz   Many  Thanks to Leor Zolman, all the code fragments in the book
                    are available in compilable form at 
                    http://www.bdsoft.com/resources/estlcode.html.  
                    
 5/ 8/01 sdm  Many  STLport debug mode is no longer the only STL
 6/27/01 pe         implementation where vector's and string's iterators
                    aren't real pointers.  The latest Dinkumware library
                    (including the one shipped with VC .NET) also uses
                    classes for these iterator types, and I'm told that
                    the same is true of the library that ships with GCC
                    3.0. 
                     
 5/ 9/01 sdm  Many  In most places where I mention arrays, I should mention
                    valarrays, too.  Like vectors, valarrays are
                    constrained to have contiguous storage, and this means
                    that pointers can be used as iterators into valarrays.

 7/28/01 jep     5  In second bullet, the summary of input iterators is subtly
                    incorrect.  Input iterators may be read more than once, but
                    they support only single-pass algorithms.  Once you've
                    incremented past an element, you can't get back to that
                    element.

 9/24/01 mm  Item 1 Sometimes, the best data structure for a problem is not in
                    the STL at all.  mm writes that "One of the biggest misuses
                    that I've seen of the STL is when maps are used instead of
                    sparse matrix data structures. ... In many applications, a
                    matrix is very sparse.  It is often the case that there is
                    just 2 to 5 entries per column, even in matrices with tens
                    of thousands of rows. ... There are highly efficient data
                    structures for doing this, and they're not very
                    complicated. ... There are lots of efficient algorithms
                    available for doing all sorts of operations on a matrix,
                    and there are various places on the internet (especially
                    www.netlib.org) that have classes that encapsulate this."
                    
 7/15/01 sdm Item 1 For another discussion of the pros and cons of different
                    containers, check out Andrew Koenig's and Barbara Moo's
                    column, "Which Container Should I Use?," in the August 2001
                    C/C++ Users Journal. 
                    
 4/28/02 sdm Item 1 In his May 2002 Dr. Dobb's Journal article, "Disk
                    Thrashing & the Pitfalls of Virtual Memory," Bartosz
                    Milewski describes another consideration to take into
                    account when choosing between vector and deque: the
                    impact of repeatedly copying objects in order to keep
                    vector's memory contiguous.

 3/21/02 ss  Items   The rules governing the conditions under which iterators
             1,26,28 are or are not invalidated fail to apply to
                     reverse_iterators.  Some operations on node-based
                     containers (e.g., insertion) that invalide no iterators MAY
                     invalidate reverse_iterators.  ss sent this example:

                       std::list<int> int_list;
                       int_list.push_back(1);
                       std::list<int>::reverse_iterator iter = int_list.rbegin();
                       std::cout << *iter;  // prints "1"
                       int_list.push_back(2);
                       std::cout << *iter;  // prints "2" (doh!)

                     If you're interested in more information on this, take a
                     look at a comp.std.c++ thread on this issue.

12/ 5/07 dd  Item 1 Another consideration is container iteration speed,
                    which generally decreases in this order:
                    vector/string (fastest iteration), deque, list,
                    set/multiset/map/multimap (slowest iteration).
                    
 9/26/01 kh     13  Technically, it would be more accurate to define
                    contiguous-memory containers as those that are assumed
                    to store more than one element per dynamically allocated
                    chunk of memory; they are not required to do so.
                    In theory, both deque and string could be implemented as
                    arrays of pointers to objects, for example, though no sane
                    implementation would do things that way.  (Very large
                    objects may be stored only one element per chunk of memory
                    in a deque, though one would have to wonder why such large
                    objects were being stored in an STL container in the first
                    place.)
 
 7/16/01 sdm Item 4 If you're interested in the technical and standardization
                    issues surrounding list::size, check out the 
                    July 2001 comp.std.c++ thread discussing the matter.

10/11/01 gn     33  gn writes:
                    
                    Regarding the declaration of the function int f(double(d))
                    at the bottom of the page, the text suggest that the
                    parentheses are ignored. Well, it depends on what d is. If
                    it is a type-name then the function is int f(double
                    (*)(d)), and that is not the same as int f(double d). The
                    d must be looked up in this case to determine if it is a
                    type-name or not. See 8.2/7.
                    
                      typedef int d;
                      int f(double(d));    // d is a type-name =>
                                           // int f(double (*)(int));
                      int d;
                      int f(double(d));    // d isn't a type-name =>
                                           // int f(double);
                    
 6/ 4/04 tb Item 7  tb argues that the Item title should make clear that this
                    Item applies only when the container owns the pointers,
                    i.e., is responsible for deleting them.  That's true, of
                    course, but I hope the discussion in the Item makes that
                    clear.  In a future edition, I may reword the Item title.

 8/26/02 sdm Item 7 Several people have written to ask about why 
                    DeleteObject::operator() takes a pointer to const, even
                    thought it's going to delete the pointer.  The answer is
                    that if it did not, it wouldn't be possible to use
                    DeleteObject on containers such as vector<const char*>.
                    There has been much debate in the C++ community over
                    whether deleting pointers-to-const should be legal, but it
                    is and it can be useful, so it's important to me that
                    DeleteObject support it.
                    
12/22/01 sdm Item 7 Windows programmers experimenting with my
                    DeleteObject class should beware that there is a
                    Windows function with the same name.  (I didn't know
                    that when I wrote the book.)
                    
 7/11/07 axm Items  Item 9 discusses how to erase while iterating, and Item 28
             9, 28  discusses how to erase using reverse_iterators, but neither
                    Item discusses how to erase while iterating with
                    reverse_iterators.  For information on this issue, see 
                    the newsgroup discussion of the issue that axm initiated.

 6/29/01 kl  44-46  "AssocContainer<int>" isn't really appropriate for map and
                    multimap.  This is true, but I can't think of a better
                    term, and I don't think the current term is too misleading.

 7/28/01 jep    46  The approach I show for erasing elements in a contiguous-
                    memory container while iterating through it does a good
                    job of maintaining iterator validity, but the time
                    complexity of the approach is quadratic.  This can
                    typically be improved to linear by using a two pass
                    strategy: 
                      1. Walk the container, writing the log for each element
                         you plan to erase (but don't erase anything yet).
                      2. Perform a range erase, e.g., by using the erase-
                         remove idiom or by using partition (or 
                         stable_partition) and then erasing.

12/ 2/02 jr     46  The code at the bottom of this page has two shortcomings:
                    (1) though it works when iterating over an entire container,
                    it's incorrect if given an arbitrary end iterator, because
                    the call to erase will invalidate the end iterator; and (2)
                    because each call to erase shifts all succeeding elements
                    down by one, the linear-looking loop really runs in
                    quadratic time.

                    Here's code that addresses both problems, where endIt is the
                    arbitrary end iterator to be used and, for consistency,
                    beginIt is an arbitrary begin iterator to be used:
        
                      vector<int>::iterator i = beginIt; 
                      while (i!=endIt && !badValue(*i)) ++i; 
                      vector<int>::iterator j = i; 

                      while (i!=endIt){ 
                        if (badValue(*i)) {
                          logFile << "Erasing " << *i << '\n'; 
                        } else { 
                          *j=*i; 
                          ++j; 
                        } 
                      ++i; 
                      } 

                      c.erase(j, endIt); 

                    Note that the second while loop is essentially a variant of
                    remove_if (see Item 32).

                    jr reports that in simple tests he performed comparing the
                    performance of this code with that on the bottom of page 46,
                    he saw speed improvements of 2-3 orders of magnitude.

11/14/01 axg Item 10 One way to avoid creating allocators with per-object state
                    is to declare all member functions static.
                    
10/11/01 gn     53  Though the book is correct that the type of the allocator
                    for ListNodes is 
                    
                      Allocator::rebind<ListNode>::other
                    
                    you'd have to express that type like this in a program:
                    
                      typename Allocator::template rebind<ListNode>::other
                    
                    Pages 7-8 explain why the "typename" is necessary, and the
                    use of "template" here is similarly required to help the
                    parser process things correctly.
                    
11/28/01 sdm Items  Matt Austern has a nice article on implementing a
             10-11  debugging allocator and allocator adapters in his
                    December 2001 CUJ column, "A Debugging Allocator."
  
!8/16/01 kh  55-56  My discussion of putting containers in shared memory is
                    incomplete and, to some degree, misleading.  As Item 15
                    demonstrates, some string implementations use the small
                    string optimization, so elements of such strings won't be
                    in shared memory unless the string objects themselves are.
                    Furthermore, even use of placement new to put containers
                    in shared memory won't put static components of those
                    containers in shared memory, and the Standard allows
                    containers to have such components (e.g., a shared empty
                    string representation); some implementations take
                    advantage of this allowance.  kh summarizes things this
                    way: "No matter how well-written your allocator
                    implementation [for shared memory], if it works, it is
                    either a matter of luck or hardwiring to a specific
                    container implementation."

11/ 5/01 sdm 60-61  An alternative to creating and using the Lock template is
                    to use Alexandrescu's and Marginean's ScopeGuard
                    technique. 
                    
11/13/01 ib  60-62  Given that manual concurrency control is a necessity, you
                    might consider using the cross-platform threading library
                    available at Boost.
                    
 8/22/01 jep    66  jep notes that "The 'aptly named max_size member function'
                    does nothing more than return a number based on the number
                    of bits in size_type.  It has nothing to do with how many
                    items may really be placed in any of the containers
                    without exceeding memory."
                    
 8/18/02 apl    69  apl argues that credit for notion that "God is in the
                    details" should go to Mies Van Der Rohe, not Einstein.  He
                    points to a column in The Atlantic online to bolser his
                    argument. 
                    
 8/19/01 hxh  72-73 Regarding Implementation B's capacity being 7 when the
                    size of the string is 5, hxh (the author of 
                    Implementation B) writes:
                    
                    At the time I wrote <string>, I could not imagine an
                    allocator that could deliver a non multiple of
                    sizeof(void*) bytes on the platforms I was targeting.  I
                    could imagine specialty allocators that could very
                    efficiently deliver 4 bytes, but not 1, 2 or 3 bytes.
                    Or 8 bytes, but probably not 5, 6 or 7.  So string takes
                    advantage of this.  If the client asks for 5 bytes, he
                    gets 7 (8 minus 1 for the terminating null).  So this
                    string really does have a minimum capacity.  It's 3.  I
                    tend to go for very small minimum capacities in order to
                    make containers of containers more efficient.
                      
 9/12/01 sdm   74   A number of people have expressed interest in the source
                    for my claim that the elements of a vector must be stored
                    in contiguous memory.  This guarantee is not in the
                    Standard itself.  Rather, it will be part of a forthcoming
                    Technical Corregendum to the Standard, something of which
                    all library implementers are certainly aware. For more
                    information on this matter, consult the official defect
                    report (Library Working Group Issue #69).
                    
 3/29/04 df     74  An alternative to "&v[0]" is "&v.front()".  df argues
                    that this is "the most explict way to do it."   To me,
                    "&v[0]" is equally explicit, but both work.

 8/17/07 abt    74  abt remarks: 
                      I don't think you should avoid calling doSomething
                      altogether just because the vector is empty. Perhaps
                      doSomething has Something useful to do, even if you give
                      it zero elements. So I think the example should be
                      changed to
                        doSomething(v.empty() ? 0 : &v[0], v.size());
                      or, perhaps even better (as Daniel Filip had suggested on
                      the errata site), 
                        doSomething(v.empty() ? 0 : &v.front(), v.size());

 7/ 8/01 dm     80  Technically, the statement at the bottom of page 79
                    may compile.  The real problem is that even if it 
                    does, the statement
                      *pb = true;
                    can't affect the value of v[0], because it's not possible
                    to have a pointer to a bit.

 7/31/01 gl Item 20 When your comparison function for an associative
                    container isn't less<T>, it's important to specify the
                    comparison function for all algorithms that will perform
                    comparisons.  An example of this issue is discussed on page
                    149 in Item 34.  Note that following the advice of Item 44
                    minimizes the chances of running into this kind of problem.

 8/22/01 jep 90-91  You don't have to create a functor class, because
                    you could use stringPtrLess's type, then pass
                    stringPtrLess as a constructor argument:
                    
                      bool stringPtrLess (string const*, string const*);
                      typedef bool (*StringPtrLess) (string const*, 
                                                     string const*);
                      set<string*, StringPtrLess> ssp(stringPtrLess);
                    
                    This is legal code, but I consider it highly ill-advised,
                    because it allows for the possibility that you have
                    multiple containers of the same type but with different
                    sort orders.  To me, that's a recipe for disaster, and
                    that's why I went out of my way to avoid mentioning it in
                    the book.
                     
 8/22/01 jep Item 21 jep writes:

                    Using less_equal is even worse than you say.  The
                    average quicksort used in sort will crash with some data
                    sets.  Neither 10A nor 10B will be in the range of
                    equal_range.  For { 9 10B 10A 11 } I got find(10) is
                    end, lower_bound(10) is 11, upper_bound(10) is 10B, and
                    equal_range(10) is [11, 10B), an invalid range.
                    
 6/20/01 cc    93   Writes cc:
                    
                    The comparison type StringPtrGreater can be
                    implemented in terms of comparison type StringPtrLess:
                    
                      struct StringPtrLess: 
                        binary_function<const string*, const string*, bool> 
                      { 
                        bool operator()(const string* ps1, 
                                        const string* ps2) const 
                        { return *ps1 < *ps2; } 
                      }; 
                    
                      struct StringPtrGreater: 
                        binary_function<const string*, const string*, bool> 
                      { 
                        bool operator()(const string* ps1, 
                                        const string* ps2) const 
                        { return StringPtrLess()(ps2, ps1); } 
                      }; 
                    
                    Not only does this ease the maintenance, but also,
                    more importantly, expresses the logic: To determine if
                    x > y, we just need to test if y < x. That is because
                    a < b and b > a are necessary and sufficient
                    conditions for each other.  

10/ 5/05 sdm Item 23 As noted above, vectors emulating sets and maps must
                    manually ensure that the data contain no duplicates.  Three
                    ways to ensure this are (1) to know a priori that the input
                    contains no duplicates, (2) to invoke the "unique"
                    algorithm on the vector after sorting it, and (3) to put
                    the data into a normal set or map during Phase 1, then copy
                    it into a vector at the end of Phase 1; use of the set or
                    map will automatically sort the data and eliminate
                    duplicates.

12/ 5/07 dd Item 23 Sorted vectors can also outperform associative containers
                    when container iteration is an important operation.  dd
                    reported that in one system he examined, iteration
                    over a vector was 35% faster than over a set.
                    
 8/ 4/01 sdm Item 23 As part of the Loki library described in his book, Modern
                    C++ Design (Addison-Wesley, 2001), and downloadable from
                    the Loki web site, Andrei Alexandrescu developed the
                    AssocVector template, a map-like container built on top of
                    sorted vectors.  If you're interested in the performance
                    improvements you might get from using a sorted vector
                    instead of a map, consider downloading AssocVector and
                    giving it a try.

 1/ 4/04 or Item 24 Another advantage to a function like efficientAddOrUpdate 
                    vis-a-vis operator[] is that use of operator[] requires
                    that the value type of the pair (i.e., the mapped_type)
                    support default construction for insertion, but
                    efficientAddOrUpdate does not.

 8/20/01 ag  110-111 Writes ag:

                    The discussion about using a generic ValueArgType to use
                    the specialized assign if present is interesting, but
                    using KeyArgType instead of key_type may trigger
                    multiple conversions for the key.  Imagine having a map
                    indexed by strings and calling
                    
                      efficientAddOrUpdate(m,"Andrea",10.5);
                    
                    With the version in the book there are three conversions
                    from KeyArgType to key_type: one in lower_bound, one in
                    key_comp and another one in insert.

11/12/01 sdm Item 25 Regarding the choice of basing hashed containers on
                    equality or equivalence, P. J. Plauger, founder of
                    Dinkumware, posted this to comp.lang.c++.moderated on
                    8/27/01: 
                    
                      Our latest version of the hash template classes aims for
                      the best of both worlds. Turns out it can hash properly
                      given either a strict weak ordering, as in operator
                      less<T>, or an inequality comparison, as in operator
                      not_equal<T>. So we add a partial specialization that
                      looks for SGI-style template parameters and invert the
                      sense of the supplied predicate. The upshot is that you
                      can use our hash tables as a drop-in replacement for
                      map/set, using a strict weak ordering, or as a drop-in
                      replacement for SGI-style hash_map/set, using an
                      (in)equality comparison.
                    
                    If you're interested in the choice between equality and
                    equivalence for hashed containers, you might want to 
                    view the thread from which this posting is taken.

 2/20/02 sdm Item 25 For information on how hash-based containers may be added
                    to the next version of the Standard Library, consult Matt
                    Austern's April 2002 CUJ column, 
                    "Hash Tables for the Standard Library."
                    
 3/26/06 txs   113  Traits are also explained in the
                    third edition of Effective C++ :-)

 5/16/03 drm Item 26 "The advice of this Item seems kind of strong. Counting 
                    in my last bit of code: 49 const_iterators, 3 iterators, 0
                    problems (so far).  I think a better slant to the Item
                    might be: be careful, const_iterators have certain
                    restrictions.  I don't see that those restrictions
                    necessarily lead to the recommendation to prefer iterator."

 9/ 4/02 ga    117  Five lines from the bottom, "const" should be
                    capitalized, because it is the first word in a sentence.

 8/22/01 jep 118-119 The Standard doesn't actually state that comparisons
                    between iterators and const_iterators must be supported.
                    Now, however, the Standardization Committee appears to be
                    on the verge of officially deciding that such comparisons
                    must be allowed.  For details, consult Library Working 
                    Group Issue #179.  While you're there, note the link to
                    Issue #280, where you'll see that whether to
                    require comparisons of reverse_iterators and 
                    const_reverse_iterators is not yet resolved.

!8/22/01 jep   121  The advance/distance idiom shown here is sanctioned by the
                    Standard for every standard container except string, and
                    it should also work for any string implementation that
                    avoids reference counting.  For strings using reference
                    counting, calling begin() may invalidate existing
                    iterators, and that leads to this problem:
                    
                      typedef string::iterator Iter;
                      typedef string::const_iterator ConstIter;
                    
                      string s;
                      ConstIter ci;
                      ...                       // make ci point into s
                    
                      Iter i(s.begin());        // calling begin
                                                // invalidates ci!
                    
                      advance(i, distance<ConstIter>(i, ci));
                                                // pass invalidated ci
                                                // to distance!
                    
                    A use of advance and distance that should work with
                    any standard container c (including strings
                    employing reference counting) is this:
                    
                      Container::difference_type d =
                        distance<ConstIter>(c.begin(), ci);
                      Iter i(c.begin());        // invalidates ci, but we
                                                // don't need it any more
                      advance(i, d);

 7/22/01 dm  Item 27 dm notes that both advance and distance are linear-time
                    operations on some containers.  The time to accomplish
                    what the advance(distance(...),...)  idiom does can be cut
                    in half for containers that lack random access as follows:
                    
                      C::iterator i(c.begin());
                      if (ci == c.end()) i = c(end();
                      else while (&*i != &*ci) ++i;                     
                    
                    Writes dm:
                    
                    This is twice as fast on average, because the while loop
                    shown above only traverses the elements once. (I timed
                    it using two different compilers. Sure enough -- about
                    twice as fast.)  Neither solution is optimum for all
                    iterator categories. The best solution is one that is
                    parameterized by the category tag to invoke the
                    advance(distance()) idiom only on random access
                    iterators, and the while loop on all others.
                      Perhaps this Item should be renamed to "Use distance and
                    advance to convert a *random access* container's
                    const_iterators to iterators."

 8/27/02 jcj Item 28 When using the range form of erase, there is no need to
                    adjust a reverse_iterator's base if it marks the end of the
                    erase range.  Consider:
                    
                      vector<int> v;
                      ...                 // Put 1-5 in v
                    
                      // Remove 2-4 from vector in example [1, 2, 3, 4, 5]
                      vector<int>::iterator ifirst =          // ifirst points
                        find(v.begin(), v.end(), 2);          //   to the 2
                      vector<int>::reverse_iterator rilast =  // rilast points
                        find(v.rbegin(), v.rend(), 4);        //   to the 4
                      v.erase(ifirst, rilast.base());         // erase 2-4,
                                                              //   inclusive
                    
 9/ 4/02 ga    133  Writes ga, "Another variation: reserve, move away/copy the
                    elements that would be moved one by one in one chunk and
                    then transform on the gap that we are left with."  I
                    believe that in some cases, this will be more efficient
                    than resize/copy. 

 6/18/01 sdm Item 31 Additional useful information on the STL's various
                    sorting options can be found in Matt Austern's
                    column in the August 2001 CUJ, "Sorting in the
                    Standard Library."

 9/21/01 fk    136  At the top of the page, begin and end should probably be
                    declared const.  (There are other places where variables
                    could be declared const, but a quick glance showed that
                    methodically adding "const" would cause some formatting
                    problems (new line breaks) and would, in some cases,
                    probably call for additional explanatory text.  Lest the
                    cure be worse than the disease, I decided to leave things
                    as they are.  If there is a second edition of this book,
                    I'll address the matter then.)

 4/ 4/06 txs   136  There's more than one way to define the median and the 75th
                    percentile.  The way I show in the book limits values to
                    those possessed by Widgets in the container, but other
                    approaches are valid.  For more information, see the
                    Wikipedia entries for median and percentile.

 9/13/07 abt   136  The initialization of goalOffset uses a floating point
                    value, but goalOffset is integral.  This elicits a warning
                    with some compilers.  In this case, we could initialize
                    with widgets.size()/4, but in the general case, we could
                    make the deliberate nature of the conversion clear by
                    using a static_cast.

 2/22/03 lfr Item 34 When using an algorithm expecting a sorted range (e.g.,
                    includes, set_union, etc.) on a standard associative
                    container (especially a map or multimap), it's important to
                    pass the correct comparison function.  The easiest way to do
                    this is to pass the result of the value_comp member
                    function:

                    typedef multimap<int, string> map1, map2;
                    ...
                    bool subMultiset = includes(map1.begin(), map1.end(),
                                                map2.begin(), map2.end(),
                                                map1.value_comp());
                    
                    This works for sets and multisets, too, because for those
                    types, value_comp returns the same thing as key_comp.
                    However, as noted in Item 44, for operations like
                    lower_bound, etc., it's generally better to use member
                    functions instead of algorithms when both are applicable.

 6/ 3/02 mkk Item 35 This Item proposes two versions of ciStringCompare, one
                    with a strcmp interface and one with an operator<
                    interface.  They have the same signature and cannot
                    coexist.  This is frustrating because one may well need
                    both, and it also makes the example in Item 19 ambiguous
                    (which one was meant?)  The example code would be more
                    useful if the second function was called ciStringLess or
                    some other distinct name.

 2/20/03 lfr   156  Because postincrement is less efficient than preincrement,
                    the if statement may be better implemented as follows:

                    if (p(*begin)) {
                      *destBegin = *begin;
                       ++destBegin;
                    }

 8/ 3/01 yjz Item 37 Writes yjz:

                    I agree that accumulate most clearly expresses what's
                    going on. Personally, that's more intuitive to me.  I
                    would definitely choose accumulate when I do simple value
                    accumulations.  But for the final example in this item, I
                    would definitely use for_each because the solution using
                    accumulate provided by this item introduces a lot of
                    overhead by calculating the average point every time the
                    operator() is called. So, supposedly, we have n elements
                    in the container, for the example using accumulate, you
                    will calculate the average of points n times. But in
                    for_each example, you only do that calculation once. For
                    this specific example, there are 2*(n-1) times of division
                    and (n-1) times of construction of temporary Point objects
                    which are not necessary.

 9/21/01 fk  Item 37 fk remarks that the accumulate approach to computing
11/29/02 gm         the average of a set of points involves multiple
                    divisions, while the for_each approach does only a single
                    division at the end.  As a result, he suggests that the
                    for_each approach may be more accurate.
                    
                    gm disagrees.  He writes: "the results of all but the
                    last of those divisions get thrown away. The actual
                    calculations that contribute to the final answer are
                    exactly the same for both versions; the only
                    difference is that the version with accumulate (1)
                    does far more divisions, (2) does a whole lot of
                    unnecessary contructions and destructions of Point
                    objects, and (3) isn't legal.  It's possible that a
                    sufficiently smart compiler might be able to eliminate
                    all that wasted effort, I suppose."  
                    
                    I responded that floating point makes my head hurt,
                    and gm replied that "the point I'm making doesn't
                    really have anything to do with floating point. The
                    results of all those extra divisions you're worried
                    about get thrown away immediately, that's all.
                    They're used to make return values from
                    PointAverage::operator(), which get passed to the next
                    invocation of PointAverage::operator() and ignored
                    there."  

10/14/01 kg  Item 37 There is a notable difference between the accumulate and
                    the for_each approaches to this problem.  When the range
                    is empty, accumulate returns Point(0,0), but calling
                    result on the functor returned from for_each yields
                    undefined behavior due to division by zero.
                    
 2/26/03 shh   159  In order to make sure that the initial summary value
                    passed to accumulate is of the appropriate type, shh
                    suggests using this form:

                    Y sum = accumulate (
                      begin,                    // acts like a T*
                      end,                      // acts like a T*
                      static_cast<Y>(initValue) // initValue need not be of type Y
                    );

 1/13/05 bxr   160  The following approach allows the average of a set of 
                    points to be computed by accumulate without its functor
                    using any side effects:

                    class AveragePoint {
                    public:
                      AveragePoint() : SumX(0), SumY(0), mv_NbrOfPoints(0) {}
                      AveragePoint(const AveragePoint& av_AveragePoint,
                                   const Point2D& Point)
                      : SumX(av_AveragePoint.SumX + Point.x),
                        SumY(av_AveragePoint.SumY + Point.y),
                        mv_NbrOfPoints(av_AveragePoint.mv_NbrOfPoints+1)
                      {}
                    
                      operator Point2D()
                      { 
                        return Point2D(SumX/mv_NbrOfPoints, SumY/mv_NbrOfPoints); 
                      }
                    };
                    
                    class PointAverage: 
                      public std::binary_function {
                    public:
                      const AveragePoint operator()(const AveragePoint& avgSoFar,
                                                    const Point2D& Point) const
                      {
                        return AveragePoint(avgSoFar, Point);
                      }
                    };
                    
                    std::list PointCont;
                    ...
                    Point2D avg = std::accumulate(PointCont.begin(),
                                                  PointCont.end(),
                                                  AveragePoint(), 
                                                  PointAverage());

 9/ 4/02 ga    161  for_each is also faster.

 8/24/01 sdm Item 39 My decision to advise readers to make predicates pure
                    functions was based on pragmatic considerations, not on
                    the Standard.  In fact, Kreft and Langer argue in their
                    April 2001 CUJ column that the Standard allows
                    predicates to have state, though they concede that the
                    problem I describe in this Item does exist in some STL
                    implementations.  The Committee ultimately resolved the
                    problem by adding wording to the standard explicitly noting
                    that function objects may be freely copied.  For details,
                    consult the Committee's notes on the matter. 
                    This resolution means that the advice of the Item should
                    really be more like "Make sure predicates behave well when
                    copied."  It also means that that the part of the Item
                    on page 169 (regarding the function anotherBadPredicate)
                    is incorrect, because the fact that there is only one copy
                    of the predicate's state means that it will behave well
                    when copied.

 5/19/03 drm   168  drm points out that my claim that "Declaring operator()
                    const in predicate classes is necessary for correct
                    behavior, but it's not sufficient" is too strong, because
                    it would be safe to modify data members that don't affect
                    the outcome of the predicate.  Such predicates would be
                    rather odd, however, so to avoid confusing the issue, I
                    have chosen to retain the current wording in the book.

 6/16/01 al  Item 39 The idea of using remove_if to eliminate the third element
                    from a range is misguided.  Implicit in my discussion is
                    the idea that remove_if will examine the elements in the
                    range from the beginning to the end, but this is not
                    required by the Standard and conceptually doesn't make
                    sense.  Even if the predicate passed to remove_if could
                    safely have state, the only thing we could reasonably
                    expect from remove_if is that the third element visited
                    would be removed; we wouldn't be able to make any
                    assumptions about which element that would be.  For more
                    on this idea, consult the April 2001 column by
                    Klaus Kreft and Angelika Langer, "Unary Predicates
                    in the STL." At the same time, it's worth noting that
                    every implementation of remove_if I know behaves like the
                    one in the book, and there are technical reasons why
                    alternative implementations are unlikely.
                    
 9/30/03 mp    188  In the operator() implementation at the top of the page, it 
                    might be preferable to write the test this way,
                      return lowVal < val && val < highVal;
                    so that val is both numerically and *physically* between
                    the bottom of the range on the left and the top of the  
                    range on the right. mp finds this clearer and also nearer
                    to the mathematical notation "lowVal < val < highVal."  (mp
                    attributes this idea to either Steve Maguire's "Writing
                    Solid Code" or "Debugging the Development Process.")

10/28/01 jep    191 Regarding the widespread use of red-black trees to
                    implement the standard associative containers, jep writes: 
                    
                    A perfectly balanced tree is impossible to rebalance after
                    insert/delete in reasonable time.  The reason that an RB
                    tree is usually used (I know of no exception other than my
                    AVL implementation) is because that was used in the
                    original.  The AVL version outperformed the RB version
                    hands down for searches.  With very high dynamics (every
                    search caused either an insert or erase), they were about
                    equal.  RB does have a better erase than AVL.  I have not
                    found time to try a deterministic skip list yet.
                    Splay-tree and treap in addition to not meeting the
                    required worst case times do not have very good average
                    times either.

10/ 5/05 sdm    200 There are now several entries in the table I would like to
                    change, but I'd have to change the corresponding text more
                    than is practical between printings.  In general, table
                    entries correspond to the easiest way to code the tests
                    such that equivalence is used when appropriate.  This is
                    explained at the bottom of page 200.  However, the second
                    entry in the last column mentions lower_bound instead of
                    equal_range, and, as pointed out on page 201, this is
                    because lower_bound is more efficient than equal_range.  As
                    a result, most entries in the table emphasize ease of
                    writing correct code, but at least one emphasizes
                    efficiency of the resulting code.  This is inconsistent.
                    If efficiency is to be emphasized (which is likely what I'd
                    do if I were to do it again), the second row would contain
                    these entries in this order,
                       find   lower_bound   find   lower_bound
                    and the third entry in the last row would be "find" instead
                    of equal_range.  This is because equal_range requires two
                    logarithmic-time searches, while find and lower_bound
                    require only one.  Also, I'd probably change the first
                    entry in the third column from "count" to "find," as I'm
                    no longer convinced that using "count" is a widespread
                    idiom for testing for membership in a set or map.

 8/16/01 kh     203 Strictly speaking, the code at the bottom of this page
                    is not standard-conformant, because library implementers
                    are permitted to add extra parameters to library
                    functions, as long as the parameters have default
                    values.  (You can read about this matter in Herb
                    Sutter's GOTW #64.)  A workaround for such a perverse
                    library implementation would be precisely what Item 46
                    suggests: use a function object to wrap the call to the
                    library function.
                    
11/14/01 yd 243-244 yd writes:  "I took your advice and turned on the
                    __STL_MEMBER_TEMPLATES flag in the SGI STL
                    configuration. However I was not able to compile, due to a
                    Microsoft bug (Q241949 in the MS knowledge base).  MSVC6
                    supports member templates, but only when they are defined
                    inside the class body. The SGI STL has many such members
                    defined out-of-body. Getting it to compile would require
                    extensive cut-and-paste throughout. I haven't checked
                    STLport, but chances are it has the same problem since
                    it's derived from SGI STL."  
                      I know from personal experience that some constructs
                    requiring member templates work with MSVC6 and STLport, so
                    this suggests that STLport has modified the SGI
                    distribution on which it is based to better work with
                    MSVC6.  That suggests that STLport's STL may be a better
                    choice than SGI's, at least as regards support for member
                    function templates under MSVC6.

  al  = Angelika Langer                      kg  = Klaus Gütter             
  mjh = Michael Hawkins                      wg  = Wayne Goertel            
  dp  = Derek Price                          gn  = Gabriel Netterdag        
  jw  = Jon Webb                             rd  = Ruediger Dreier          
  lz  = Leor Zolman                          ma  = Motti Abramsky           
  cc  = Charles Cao                          yd  = Yigal Dayan              
  pe  = Phil Edwards                         ib  = Ian Bruntlett            
  js  = Jim Scheller                         axg = Adam Gates               
  kl  = Laushway Kevin                       sk  = Stefan Kuhlins           
  jk  = Jason Kenny                          mm  = Marc Meketon             
  cm  = Carl Manaster                        jdl = Jonathan Low             
  hs  = Herb Sutter                          lfr = Fraser Ross              
  ajf = Albert J. Franklin                   ss  = Stan Sulsky              
  gk  = George King                          sxb = Scott Blachowicz         
  dm  = Dave Miller                          en  = Eric Niebler             
  hh  = Harold Howe                          mkk = Mary Kuhner              
  jf  = John Fuller                          kes = Keith Stanley            
  tm  = Tim McCarthy                         ckl = Chan Ki Lok              
  pc  = Paolo Carlini                        apl = Alan Lehotsky            
  jeh = John Hershberger                     jcj = Jeffrey C. Jacobs        
  imt = Igor Mikolic-Torreira                pn  = Phillip Ngan             
  sb  = Stephan Bergmann                     wb  = Wolfram Burkhardt        
  ras = Robert Allan Schwartz                as  = Adrian Spermezan         
  jep = John Potter                          gm  = Gareth McCaughan         
  gl  = Guillaume Laurent                    ga  = Giulio Agostini          
  yjz = Yingjun Zhang                        cb  = Charles Brockman         
  dg  = David Grigsby                        shh = Seyed H. Haeri           
  kh  = Kevlin Henney                        jr  = Johan Rade               
  sp  = Sanjay Pattni                        drm = Doug Morgan              
  hxh = Howard Hinnant                       mp  = Matt Page                
  ja  = Jesper Andersen                      mc  = Moshe Cohen              
  jtw = Jing Tao Wang                        jp  = Jim Phillips             
  ag  = Andrea Griffini                      or  = Olaf Raeke               
  ab  = André Blavier                        df  = Daniel Filip             
  ds  = Dan Schmidt                          tb  = Tim Buchowski            
  bww = Bradley White                        he  = Hans Eckardt             
  dxc = David X Callaway                     gc  = Guru Chandar             
  fk  = Feliks Kluzniak                      sk  = Sharad Kala              
  ap  = Adam Petersen                        dxm = Declan Moran             
  db  = Day Barr                             nds = Nick de Smith            
  fxs = Shlomi Frank                         bxr = Bert Rodiers 
  af  = Andy Fyfe                            vxs = Vincent Stojanov
  mxd = Mark Davis                           txs = Thomas Schell
  cmm = Cameron Mac Minn                     rxp = Randy Parker
  gxu = Giora Unger                          cxb = Christos Bellos
  nxd = Niels Dekker                         axm = Adam McLaurin
  abt = Allen B. Taylor                      cpj = Chris Just
  dmr = Martin Rottinger                     dd  = Dibyendu Das
  mxs = Molly Sharp