I've just completed my customary year-end updates to all my publications'
errata lists. The revised lists are at the usual URLs; you'll find links
to them at http://www.aristeia.com/books.html#errataLinks
As a mailing-list exclusive, below you'll find summaries of the new
entries.
As always, I hope you find the errata useful, and I apologize for their
needing to exist. Sigh.
Scott
NEW ENTRIES FOR EFFECTIVE C++:
Interesting Comments:
DATE
REPORTED WHO PAGES WHAT
-------- --- ------- ----------------------------------------------------------
11/13/03 dfc 9, The code for the String class isn't exception safe. When
73 I wrote the book, I frankly wasn't concerned about
exception safety, but I should have been. When I write
the third edition of the book, I'll be careful to pay
attention to exception safety throughout.
12/10/03 sn Item 12 As Item 11 explains, bitwise copy is virtually always
incorrect for pointer data members, but it is often
simpler to "do the right thing" via assignment vis-a-vis
initialization for pointer data members. So it may make
sense to assign to pointer data members instead of
initializing them.
NEW ENTRIES FOR MORE EFFECTIVE C++:
Interesting Comments:
DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
12/18/03 sdm Item 31 Nat Goodspeed's article in the January 2004 DDJ, "Double
Dispatch Revisited", contributes an interesting new
approach to implementing support for double dispatch that
also supports inheritance.
NEW ENTRIES FOR EFFECTIVE STL:
DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
9/17/03 hs 99 The claim in the 3rd prose para that map nodes
could be put in write-only memory is dubious.
Among other things, the value part of the pair
is generally modifiable, and the node almost
certainly has pointers to its children, which
may change over time.
9/17/03 hs 163 In the middle of the page,
DoSomething::operator() should be declared
public.
12/22/03 mc 201 I should make clearer in my discussion of
multimap::find vs. multimap::lower_bound that
only lower_bound is guaranteed to locate the
*first* element with a given key value; find
is guaranteed only to locate *some* element
with the given key value. I may want to make
this clearer in the tables on pg. 200 and the
inside front cover, too.
7/28/03 jp 206 The problem would be in agreement with the
code, and clearer, if it said simply "get rid
of all the elements in the vector whose value
is less than x and that occur after the last
value at least as big as y".
Interesting Comments:
DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
11/04/03 sdm 67 According to my most recent tests, the last para on the
page continues to be true, but it's worth noting that
the vector that ships with VC7.1 (Visual C++ .NET 2003)
performs 17 reallocations. Instead of doubling the
capacity each time, it appears to grow at a rate of 1.5
instead.
NEW ENTRIES FOR THE EFFECTIVE C++ CD:
DATE DATE
REPORTED WHO WHAT FIXED
-------- --- ------------------------------------------------------- --------
3/12/02 ga In the final comment preceding P12 of M2 (Item
chunking), "hierarch" ==> "hierarchy".
3/12/02 ga In P2 of M4 (Item chunking), there is an extra space in
"( Item 28)".
Monday, December 29, 2003
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment