Three things:
- I've updated the errata lists for all my books.
- My "Counting Objects in C++" article is now available in Chinese.
- TCS3 Registration will open soon.

Book Errata Updates
-------------------
I've just updated the errata lists for all my C++ books, and you can find
them at the usual locations:

EC++: http://www.aristeia.com/BookErrata/ec++2e-errata_frames.html
MEC++: http://www.aristeia.com/BookErrata/mec++-errata_frames.html
ESTL: http://www.aristeia.com/BookErrata/estl1e-errata_frames.html

At the end of this message I've also appended just the new entries for each
list. These are easier to peruse to see if you care about any of the
changes. Please bear in mind that these lists are in a funny format I use
internally, so they're neither fully clean text nor fully clean HTML. I
clean them up when I add them to the errata lists, so if you're confused by
an entry below, please consult the real errata list online.


"Counting Objects in C++" in Chinese
------------------------------------
Been dying to read my 1998 CUJ article, "Counting Objects in C++" in
Chinese? Now you can, as it's available at
http://www.china-pub.com/computers/emook/1575/info.htm. My Chinese is a
little rusty, I'm afraid, so I have no idea whether the translation is any
good :-)


TCS3 Registration
-----------------
Registration for this October's "THE C++ Seminar" will open soon. I'll
post again a few days after registration opens, but if you want to be the
first on your block to sign up, you'll want to sign up for the seminar's
mailing list, because those people get the very first notice about
registration. You can put yourself on the mailing list (and also read
about the seminar) at http://www.gotw.ca/cpp_seminar/.

Scott


****************************************************
* NEW ERRATA FOR EFFECTIVE C++ *
****************************************************

Errata:

DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
1/22/02 fb 107 The information on this page is correct for
integral types, but for floating point types,
it's not. For floating point types, the data on
the "minimum possible value" in <limits>,
<limits.h>, and <climits> is for the minimum
representable <em>positive number</em>, e.g.,
both DBL_MIN and numeric_limits<double>::min()
are greater than zero. For a floating point
type FPT, the minimum representable value is
typically -numeric_limits<FPT>::max(), though
the Standard does not guarantee this.

2/14/02 sdm 112 A <a
href="http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=MPG.16\
d4d3db6c6093a09896bb%40news.hevanet.com&rnum=3&prev=/groups%3Fq%3Dspace%2Bage%2B\
null%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den">thread in comp.lang.c++.moderated</a>
sparked in me
the realization that my approach to having NULL
implicitly convert to all possible member
function pointer types was doomed to failure.
Instead, it is necessary to use different member
templates for member function pointers taking
different numbers of arguments. In addition,
const and non-const member function pointers must
be handled separately. (For details on how to do
this, see <a
href="http://www.ddj.com/articles/1999/9910/9910b/9910b.htm">my article on
implementing an
operator->* for smart pointers</a>.)
I plan to remove all mention of converting NULL
to member function pointers. That will free up
enough space to fix and explain why the NULL I'm
implementing requires initialization (see the
erratum immediately above).

Interesting Comments:

DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
1/ 8/02 yy 15 The "enum hack" may be better than static const objects in
two cases. The first is when compilers fail to optimize
away the storage for the const object; enums occupy no
storage. The second is if compilers generate code to
initialize the value of the const object at runtime instead
of at load time. Because enums occupy no storage, there is
no storage to initialize.

6/14/02 es 66 Regarding my comment after the second code example that I
know of no practical use for things like (w1 = w2) = w3,
es offers the following, which do strike me as reasonable:

string str1;
string str2("123456");

(str1 =str2).replace(2, 2, "abcdefgh");
(str1 +=str2).replace(5, 2, "XYZ");

6/ 4/02 ai 72 ai writes: "In your description about programmers writing
"a = a;" you say it's silly, but point out that it could be
caused by reference aliasing. I've also noticed it done by
programmers new to C++ to get rid of the "usused
variable/parameter" warning."



****************************************************
* NEW ERRATA FOR MORE EFFECTIVE C++ *
****************************************************

Errata:

DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
1/25/02 csp 4 In last line,
http://www.sgi.com/Technology/STL/ ==&gt;
http://www.sgi.com/tech/stl/

3/12/02 ga 14 The comments describing the calls to update
aren't as clear as they could be.

1/ 8/02 sdm 52 Bad line break: "theAudi-oClip" ==&gt;
"theAudio-Clip"

1/ 8/02 sdm 76 Bad line break: "conver-tUnexpected" ==&gt;
"convert-Unexpected"

5/ 5/02 ar 120 Bad line break: "runt-ime" ==&gt; "run-time"

6/ 4/02 sdm 208 Bad line break in last prose paragraph:
"Coun-tHolder" ==&gt; "Count-Holder". (An entry
above for 2/6/98 says this was fixed on 6/6/98,
but apparently that fix got lost somewhere
between my computer and the printer.)

! 5/30/02 agb 210 makeCopy should invoke
counter-&gt;markUnshareable() before returning.
(The need for this fix is obviated by the fix
for wcm's bug report of 3/22/01 that points out
that having RCIPtr try to handle COW
automatically is a design doomed to failure.)

! 5/ 7/02 mt 238 The footnote suggests identifying a class by the
address of its associated type_info object, but
there is no guarantee that each class has only
one type_info object. In fact, I am now aware of
an implementation that generates multiple
type_info objects for a class. I now believe
that the best way to identify classes is to wrap
type_info objects inside other objects that are
easier to work with. Andrei Alexandrescu has
written such a wrapper class called TypeInfo,
described it in his <em>Modern C++ Design</em>, and
implemented it in his Loki library.

5/ 5/02 ar 261 I should note that dynamic_cast throws an
exception only because it is a cast to a
reference. dynamic_casting to a pointer would
return a null pointer if the cast failed.

Interesting Comments:

DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
5/ 5/02 ar 272-3 extern "C" and extern "C++" are actually different types,
making something like this illegal:

extern int foo(double d);
extern "C" int bar(double d);

int (*ifp)(double d) = foo; /* OK */
int (*ifp)(double d) = bar; /* type mismatch */

I.e., assigning an extern "C" function to a pointer to
a C++ function isn't allowed. Most compilers fail to
enforce this restriction. (BTW, the Standard supports
both extern "C" and extern "C++". There is little use
for the latter, as it is the default language linkage.)



****************************************************
* NEW ERRATA FOR EFFECTIVE STL *
****************************************************

Errata:

DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
5/24/02 en Item 1 Add a bullet with the question, "Does swapping
containers invalidate pointers, references, or
iterators?" If so, string is out, as noted in
<a href="">the bug report by ja and en for page 79
above</a>.

2/ 5/02 sdm 18 The text suggests that the WCIterator typedef
(near the bottom of the page) adds abstraction,
but it doesn't. WidgetContainer::iterator is
just as abstract, because iterator is itself an
abstraction. typedefs for iterator types are
still attractive, however, because they can save
a lot of typing (e.g., WCIterator instead of
WidgetContainer::iterator).

5/22/02 sxb 25 The para after the 1st code fragment suggests that
the best solution involves no more than 1 function
call, but the shown solution involves four!

7/ 3/02 kes 67 To third bullet, add a remark that calling
reserve never changes the number of objects in
the container, hence never calls constructors or
destructors.

2/ 4/02 sdm 106 In the lookup code using lower_bound (near the
middle of the page), the test should be this
instead of what is in the book:
if (i != vd.end() && !DataCompare()(s, *i)) ...
The code in the book assumes that lower_bound
used "<" as its comparison function, but the
call to sort used a DataCompare object. In this
particular example, the two tests do the same
thing, but in general, it is critical to ensure
that lookups in a sorted vector are done using
the same comparison function as was used to sort
the vector.

3/16/02 lfr 124 The last word of the second sentence of the last
unbulleted paragraph has "i" in the wrong font.

4/ 2/02 lfr 138 At end of page, remind readers that when sorting
containers of pointers, they'll almost always
want to define a dereferencing comparison
function. Xref Item 20.

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.

1/ 8/02 sdm 169 In code comment, "widget" should be capitalized
in "pointer-to-widget". Also, two comments on
this page should be reworded. It's the <em>Widgets</em>
that are or are not interesting, not the pointers
to them.

1/29/02 lfr 176 Last sentence of second-to-last para is missing
the word "to".


Interesting Comments:

DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
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 <a
href="http://groups.google.com/groups?hl=en&threadm=MPG.170c4b7b1508d1539896c8%4\
0news.hevanet.com&rnum=1&prev=/groups%3Fq%3Dauthor%253Asmeyers%40aristeia.com%26\
hl%3Den%26safe%3Doff%26btnG%3DGoogle%2BSearch%26meta%3Dsite%253Dgroups">comp.std\
.c++ thread on this issue</a>.

4/28/02 sdm Item 1 In his May 2002 DDJ 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.

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
href="http://www.cuj.com/experts/1912/austern.htm">A Debugging Allocator</a>."

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,
"<a href="http://www.cuj.com/experts/2004/austern.htm">Hash
Tables for the Standard Library</a>."