ESTL and MEC++ Errata Pages Updated

I just updated the errata pages for Effective STL (ESTL) and for More
Effective C++ (MEC++). Here are links:

ESTL: http://www.aristeia.com/BookErrata/estl1e-errata.html
MEC++: http://www.aristeia.com/BookErrata/mec++-errata_frames.html

New entries for both books are below.

I hope to update the errata page for Effective C++ by the end of this
month. I'll let you know when I do.

Scott


----------------------------------------------------------------------
NEW ENTRIES FOR ESTL
----------------------------------------------------------------------
Bugs:

DATE
REPORTED WHO PAGES WHAT
-------- --- ----- ------------------------------------------------
2/ 1/03 fr 90 Missing colon at end of page. (The missing colon is
actually deliberate, but replacing "try" with "try
this:" will probably be clearer, so that's the change
I'll make.)

1/31/03 fr 91 Include an xref to Item 7 near the definition for
DereferenceLess for readers who are confused about
why DereferenceLess is a non-template struct
containing a templatized operator().

4/18/03 lz 157 In 1st line, "many elements" ==> "many elements
with a particular value"

2/26/03 shh 166 In the third bullet point on the page, "returns
true or false" ==> "returns true or false (or
something that can be implicitly converted to
true or false)."

2/26/03 shh 211 In line 5 of 4th prose para, "do this is with"
==> "do this with"


Interesting Comments:

DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
7/16/01 sdm Item 4 If you're interested in the technical and standardization
issues surrounding list::size, check out the July 2001
href="http://groups.google.com/groups?hl=en&lr=lang_en|lang_de&ie=UTF-8&oe=UTF-8\
&threadm=uZj47.33018%24WS4.5267300%40news6-win.server.ntlworld.com&rnum=1&prev=/\
groups%3Fhl%3Den%26lr%3Dlang_en%257Clang_de%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Du\
Zj47.33018%2524WS4.5267300%2540news6-win.server.ntlworld.com"
target="_blank">comp.std.c++
thread discussing the matter.

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::iterator i = beginIt;
while(i!=endIt && !badValue(*i)) ++i;
vector::iterator j = i;

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

c.erase(j, end);

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.

2/22/03 fr 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 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.

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

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

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(initValue) // initValue need not be of type
Y
);



----------------------------------------------------------------------
NEW ENTRIES FOR MEC++
----------------------------------------------------------------------

Bugs:

DATE
REPORTED WHO PAGES WHAT
-------- --- ----- ------------------------------------------------
8/14/02 sdm 66-67 The inheritance-based conversions described on
these pages apply only to public inheritance.
For non-public inheritance, things get a bit more
complicated. For details, including a rationale
for the behavior, consult the July 2001 CUJ
column by Jim Hyslop and Herb Sutter,
target="_blank">"Baseless Exceptions."

1/ 6/03 ais 67 In the examples near the top of the page, it
would be good to note that catch-by-value can
lead to the slicing problem, a topic that is
discussed on page 70 in Item 13.

12/ 6/02 ddg 99 In last sentence "When countChar returns," ==>
"When the statement containing the call to
countChar finishes executing,"