Impending Effective STL Errata List Update

Later today, I'll update the online errata list for Effective STL. As a
mailing list exclusive, here are the changes I'll be making. By the time
these make it to the web site, they may have been massaged somewhat, but
this is what I'll be working from.

Please note in particular the entry for page 91, because it seems to have
been confusing a lot of people recently.

Thanks,

Scott


DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
11/29/02 gm 44 Regarding the paragraph after the first code
example, the call to erase can't take
logarithmic time in general, because a multi
container might consist entirely of elements
with the value to be removed. gm notes that
"The correct statement, guaranteed true by the
Standard, is: it takes time O(log(n)+k) where n
is the size of the container and k is the number
of items to be erased."

9/ 4/02 ga 46 In the for loop in the first code example,
"AssocContainer" should be entirely in italics.

11/ 6/02 wb 57 In the second code example, the
SpecificHeapAllocator template is missing the
word "class" at the beginning of the template
definition.

7/13/02 ckl 91 In first code example, ssp's type should be
declared to be set.

1/12/03 as 108 Regarding the second-to-last paragraph on the
page, as points out that "only the assigment
operator is 'unnecessary', a temporary Widget is
going to be constructed anyhow, so you have in
balance a (useless) construction/destruction
plus an assigment OVER a (useful)
construction/destruction.'

9/ 4/02 ga 141 At end of second prose paragraph, "...you should
probably be calling partition..." ==> "...you
should probably be calling partition or
stable_partition..."

9/25/02 pn 171-172 Some examples here fail to explicitly state that
inheritance from e.g., std::binary_function is
public. This is inconsistent with what I do
elsewhere in the book, e.g., on pp. 178-179. I
should check all the examples to make sure I'm
consistent.

11/ 2/02 cb 253 In column 1, the entry for istream_iterators
mentioning operator<< should mention operator>>.

11/ 2/02 cb 255 In column 2, the entry for operator<< should
mention operator>>.

Interesting Comments:

DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
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

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 I did not, it wouldn't be possible to use
DeleteObject on containers such as vector.
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.

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 href="http://www.theatlantic.com/issues/2000/01/001wordcourt.htm"
target="_blank">a column in The Atlantic online to bolser his
argument.

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

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 v;
... // Put 1-5 in v

// Remove 2-4 from vector in example [1, 2, 3, 4, 5]
vector::iterator ifirst = // ifirst points
find(v.begin(), v.end(), 2); // to the 2
vector::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.

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



I'm also going to update some of the "Interesting comments" about Item 37,
but those updates are not shown here, sorry.