First ESTL Errata; InformIT Sale on my Books

Two things:
- First ESTL Errata list.
- 35% off on my books at InformIT.


ESTL ERRATA LIST
================

I'm pleased to report that ESTL is already up for a second printing, giving
rise to the possibility that Amazon will finally stock enough copies to
avoid having to list the book's availability as "usually ships in 4-6
weeks." Grumble. Sometime this summer I'll find the time to post the
changes to the ESTL errata page, but until then, here's a mailing list
exclusive: a sneak preview of the first list of ESTL errata and
"interesting comments." Some of the formatting is a little odd, because
it's semi-ready to be dropped into an HTML document.

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

6/21/01 jw 136 In the last comment in the code example, 6/21/01
"goalPosition now points" ==>
"begin + goalOffset now points"

6/26/01 mjh 164 "containing lot of data" ==> "containing lots 6/21/01
of data"

5/ 7/01 sdm 228 Add to [26] that the article and the software it 6/21/01
describes can be downloaded from
http://www.bdsoft.com/tools/stlfilt.html.

6/26/01 dp 228 URLs for both columns by Matt Austern ([24] and 6/21/01
the second bullet after [27]) end in .htm, not
.html. (I checked all the URLs shortly before
publication, so these must have changed right
after the book was initially printed.)

Interesting Comments:

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
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.

6/20/01 cc 93 Writes cc:

The comparison type StringPtrGreater can be
implemented in terms of comparison type StringPtrLess:

struct StringPtrLess:
binary_function
{
bool operator()(const string* ps1, const string* ps2)
const
{ return *ps1 < *ps2; } }; struct StringPtrGreater: binary_function
{
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 <> a are necessary and sufficient
conditions for each other.

If we want a pair of generic dereferencing less and
greater functor class instead of StringPtrLess and
StringPtrGreater, we can do the same:

template
struct dereference_less: std::binary_function
{
bool operator()(const T* p1, const T* p2) const
{ return *p1 < *p2; } }; template
struct dereference_greater: std::binary_function
{
bool operator()(const T* p1, const T* p2) const
{ return dereference_less()(p2, p1); }
};

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,"
http://www.cuj.com/experts/1908/austern.htm.

6/16/01 al Item 39 The technical information in this Item is correct, but
the idea of using remove_if to eliminate every third
element from a range is fundamentally 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 really 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 ONE THIRD of the elements in
the range would be removed; we wouldn't be able to
make any assumptions about WHICH elements would be
removed. For more on this idea, consult the April
2001 column by Klaus Kreft and Angelika Langer, "Unary
Predicates in the STL,"
http://www.cuj.com/experts/1904/langer.htm. At the
same time, it's worth noting that every implementation
of remove I know behaves like the one in the book, and
there are reasons why alternative implementations are
unlikely. In practice, then, the discussion in Item
39 is accurate. Still, its underlying conceptual
validity is flawed.


INFORMIT SALE ON MY BOOKS
=========================

InformIT is offering 35% off on all three of my C++ books until July 13.
This is the same discount I get as an author, and it's better than anything
BestBookBuys.com could find. This is from the InformIT newsletter I was
recently sent:

Bonus! For a limited time only, InformIT offers 35% off
the following Scott Meyers titles in the Book Store;
"Effective C++," "More Effective C++," and "Effective STL."

Find 35% savings on Scott's books at:

Effective C++
http://www.informit.com/newsletter.asp?link=614

More Effective C++
http://www.informit.com/newsletter.asp?link=615

Effective STL
http://www.informit.com/newsletter.asp?link=616

Remember, you need n+2 copies of each of my books, where n is the number of
cars you have. That's one copy for home, one for the office, and one for
each car -- for when you're stuck in traffic :-)

Scott
+---------------------------------------------------+
Check out THE C++ Seminar: 3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/
+---------------------------------------------------+