Monday, December 29, 2003

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.

Friday, December 26, 2003

Recently, I had my nth telephone call explaining the facts of publishinglife to a prospective book author, and it finally convinced me to dosomething I've been threatening to do for years: write up some comments onthe topic. 12,000 words and several rounds of feedback from authors andeditors later, you can see the result athttp://www.aristeia.com/authorAdvice.html It's my hope that prospectiveauthors will find the information interesting and useful, while armchairauthors will at least find it interesting.

Thursday, December 18, 2003

In March of last year, I posted a message to this list explaining that myEffective C++ CD doesn't display properly with version 6 browsers, and Isolicited patches to address the problems. I got a patched set of filesfor IE6 from Attila Feher, but to my frustration and disappointment, theydisappeared into the Legal Department at Addsion-Wesley and never came out,so I was unable to make them publicly available.

Earlier this month, however, I got a note from Ian Roberts explaining whatchanges needed to be made to the CD's files, so I took the opportunity towrite a program to perform the edits automatically. This program, CDFix,is now available at http://www.aristeia.com/BookErrata/CDFix.zipI'm adopting a "Don't Ask, Don't Tell" policy with respect to AW's LegalDepartment: I'm not telling them about the program, and I'm hoping theydon't tell me to stop distributing it :-)

I encourage you to give it a try if you'd like to use the CD with IE6. Ifit works, great. If not, you can always delete the edited files and fallback on the originals on the CD. And if you find ways to improve CDFix,e.g., to make it also edit the CD's files so that they work better withother browsers, please let me know.

Monday, December 8, 2003

I've updated my "Upcoming Talks" page with new conference talks in Februaryand March. In February, I'll be giving a tutorial at the Embedded WorldExhibition & Conference in Nürnberg, Germany. In March, I'll be givingseveral talks at the Software Development Conference in Santa Clara,California. One of those talks (the one on double-checked locking) isbased on new work that Andrei Alexandrescu and I have been doing. Forlinks to the details on all these talks, consulthttp://www.aristeia.com/seminars_frames.html

Also, this is a final reminder that next Monday I'll be giving a full-dayseminar at OGI in Beaverton, Oregon, on making effective use of C++ inembedded systems. If you're interested in how compilers treat differentlanguage constructs, the ins and outs of avoiding code bloat (especially asregards templates), how to effectively model memory-mapped IO, or how tomake sure you don't run into trouble by confusing units like miles/hourwith different units like kilometers/second, you might want to considerattending, because these topics and more are on the docket. You'll find alink to details on this talk at the same page I mentioned above.

I hope to see you at one or more of these talks. In the meantime,Happy Holidays :-)

Wednesday, October 22, 2003

During the course of the past year, my most popular C++ seminar has been my
new one on making effective use of C++ in an embedded environment. For
whatever reason, I've offered this as an open-enrollment course several
times in Europe, but never as an open-enrollment course in the USA. Until
now. On Monday, December 15, I'll be presenting this seminar in Beaverton,
Oregon, and if you're working with embedded systems and are interested in
how to use C++ in that environment or how to *better* use C++ in that
environment, I encourage you to consider attending.

For details on the seminar, consult the web page at
http://cpd.ogi.edu/courseSpecific.asp?pam=1399. I hope to see you in
December.

Tuesday, October 7, 2003

EC++ and MEC++ are up for new printings (the 15th and 17th, respectively,
on the off chance you care), so I took the opportunity to update the errata
lists for both them and ESTL. You'll find the updated errata lists at the
usual locations:

Below I've appended the new entries for each list. These are easier to
peruse to see if you care about any of the changes.

I haven't actually made the changes for the new printings yet, but when I
do, I'll update the EC++ and MEC++ errata lists to show the fix dates for
the changes that will appear in the next printings. That should be done by
next week, so check in with the errata lists then if you're interested in
how the new printings will differ from the current ones.

Scott

PS - Interested in a glimpse at new functionality being added to C++'s
standard library? Check out
http://std.dkuug.dk/jtc1/sc22/wg21/docs/library_technical_report.html

DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
9/18/03 ss 99 The function returnStudent is dangerously
declared on this page, because it returns a
reference to what could be a temporary object.
For details, consult FAQ 32.08 of C++ Faqs by
Cline, Lomow, and Girou.

8/13/03 mc 222 There is more to the Singleton pattern than I
describe in this Item. In particular, I make no
mention of how to limit instantiation of a
singleton class to one. The technique is
clearly related to Singleton, but as mc notes,
"You can't spell 'singleton' without spelling
'single.'"

7/ 1/03 sv 108 The last sentence says you *must* use overloading, but if
you are willing to change the API, you have other choices,
e.g., you could pass a vector of values.

5/19/03 sdm Item 34 Because it's not possible to declare nested classes
without defining the class in which they are nested,
nested classes can lead to unnecessary compilation
dependencies. An alternative design is to unnest the
class and include both classes in the same namespace.
However, this is viable only when the nested class is
public, because namespaces offer no encapsulation.

6/11/03 sf Item 38 A drawback to the advice in this Item is that callers
going through the derived class interface must specify
all parameter values; the default parameter values
apply only via the base class interface. An
alternative design is to respecify the (same) default
value in each derived class, but then if the default is
changed in the base class, all derived classes must be
updated with the new value, too.

8/13/03 mc Item 43 Slightly edited, mc writes: "You are not completely
fair in this Item. The trick with auxillary classes is
needed in order to allow overloading of any
functionalities involved in the name clash, but the
clumsiness and the lack of virtual behavior are not
valid arguments. Explicit qualification is clumsy, but
so is explicit upcasting of pointers (it takes more
than one line, compare upper page 196 with middle page
197). So clumsiness is not the argument here. Moreover,
calling pls->draw(); on page 197 would still be an
error just as on page 196, so don't bad-mouth the first
approach on that account. Reversely, applying the
pointer upcast trick on page 196 instead would conserve
the virtual behavior. So the only argument left is that
only one of the methods can be overloaded, the other
will be lost (this is reason enough to apply the
technique you offer). In the end, there's no error in
your text, but I think that the code and the
formulation makes the reader focus on the wrong aspects
of the problem."

****************************************************
* NEW ENTRIES FOR MORE EFFECTIVE C++ *
****************************************************

! 6/ 7/03 mh 266 2nd and 3rd paras discuss the assumption thatbase classes have no data. The correct assumptionis that *derived* classes have no data.

Interesting Comments:

DATEREPORTED WHO PAGES WHAT-------- --- ----- -----------------------------------------------------------6/ 3/03 sxb 202 The bug for these pages reported by ct on 9/16/98 is206 incorrect, because when RCPTR::operator= is called witha raw pointer as an argument (e.g., p->next), atemporary RCPtr will be created from the raw pointer,hence the reference count won't go to 0 whenremoveReference is called. (I'll keep the code in thebook as is, because it behaves correctly, and I don'twant to mess with code in the book any more often thanI have to.)

5/19/03 drm 168 My claim that "Declaring operator() const inpredicate classes is necessary for correctbehavior, but it's not sufficient" is too strong.E.g., it would be safe to modify data members thatdon't affect the outcome of the predicate. Reword.

DATEREPORTED WHO PAGES WHAT-------- --- ----- -----------------------------------------------------------9/30/03 mp 188 In the operator() implementation at the top of the page, itmight be preferable to write the test this way,return lowVal < val && val < highVal;so that val is both numerically and *physically* betweenthe bottom of the range on the left and the top of therange on the right. mp finds this clearer and also nearerto the mathematical notation "lowVal < val < highVal." (mpattributes this idea to either Steve Maguire's "WritingSolid Code" or "Debugging the Development Process."

5/16/03 drm Item 26 "The advice of this Item seems kind of strong. Countingin my last bit of code: 49 const_iterators, 3 iterators, 0problems (so far). I think a better slant to the Itemmight be: be careful, const_iterators have certainrestrictions. I don't see that those restrictionsnecessarily lead to the recommendation to prefer iterator."

The Oregon IEEE Computer and Communications societies asked me to be theirOctober speaker, so next Thursday (October 16) I'll be giving a talk on"The Keyhole Problem" at OGI in Beaverton. You can find all the details athttp://www.ieee-or.org/events/EventDetails.asp?eventid=187 andhttp://cpd.ogi.edu/class.asp?n=04-IEEE-1016

Thursday, October 2, 2003

The second book in my Effective Software Development Series has just comeout, Elliotte Rusty Harold's "Effective XML." Many books have beenpublished that mimic the format of my "Effective" books, but this is thefirst one to come out where I offered advice to the author on how to bettermake the book "work." Rusty is an established author, so he knows how towrite, and his knowledge of XML is outstanding. I think you'll find that"Effective XML" offers exactly what the subtitle promises: "50 SpecificWays to Improve Your XML."

You can read more about the book athttp://www.awprofessional.com/catalog/product.asp?product_id={8E524FFF-F58B-4C5A\-BBC8-6E02DC159996}&session_id={0994EFB6-20AC-468B-8C72-2603CCFD9EBF}

Tuesday, July 22, 2003

For over a year now, I've been interested in what I call "keyholes" in
software: gratuitous restrictions on what can been seen or expressed.
Keyholes arise in software written in any language and for any domain; they
exist in both web-based and native applications. As a result, this
research is separate from my work on C++ programming.

I've decided that my next book will be about keyholes. In particular,
about why they are harmful and how programmers can avoid them. I've set up
a web site devoted to the project, "The Keyhole Problem." I'll post
chapter drafts there for people to offer feedback on. In addition,
Artima.com has graciously offered to host a mailing list devoted to
discussion of the book material in particular and keyholes in general.

If you're interested in learning more about this project and/or signing up
for the Keyholes Mailing List, please visit the project's web page,
http://www.aristeia.com/TKP/ There you'll find a draft paper from last
summer that gives a good overview of what I mean by keyholes, and you'll
also find a draft book chapter. If you're interested in reading the
chapter, I suggest you wait a few days, because I plan to post a revised
version of that chapter by the end of the week. (When the revised chapter
is available, I'll post to the Keyholes mailing list, not to this list.)

Speaking of writing books, you may recall that in March, I announced that I
was going to work on a new edition of Effective C++. That's happening,
too. When there's more to say on that front, members of my mailing list
will be the first to know, but for now, I'll just say that that project is
proceeding concurrently with my keyholes research.

Also on the writing front, the next book in my Effective Software
Development Series is nearing publication: Elliotte Rusty Harold's
"Effective XML." It's organized like my "Effective C++," and I think that
Rusty does a great job of applying that format to XML development. The
book is slated for publication in September. When it comes out, I'll let
you know. In the meantime, you can get a flavor for the book at
http://www.ibiblio.org/xml/books/effectivexml/

Saturday, June 7, 2003

A little over a year ago, I announced that I was working with Addison
Wesley on a new book series, the Effective Software Development Series.
Now I'm pleased to announce that the first book in the series has come out.
It's "Code Reading" by Diomidis Spinellis, and I think it's really good.
(Duh. It wouldn't be in the series if I didn't.)

The subtitle of the book is "The Open Source Perspective," and at one
point, I remarked to Diomidis that the most accurate title for the book
would actually be something like "Everything you need to know about
examining open source software projects."

Fundamentally, the book is about how to go about making enough sense of
unfamiliar software systems so that you can modify or extend them. All of
the examples are from Open Source projects, and the book ships with a CD
containing the full source of everything the book mentions. That's some 7
millions lines of code on the CD.

You can find more information about Code Reading at
http://www.awprofessional.com/catalog/product.asp?product_id={DE5EA6BB-1743-406B\
-A680-D1B335BA7EA2}

I hope you like this opening salvo in the Effective Software Development
Series.

Friday, April 25, 2003

I just updated the errata list for Effective C++. As always, it's at
http://www.aristeia.com/BookErrata/ec++2e-errata_frames.html A detailed
list of changes (in the usual pseudo-HTML I use internally) is listed
below. In conjunction with the recent updates I made to the errata pages
for ESTL and MEC++, I'm pleased to report that all the problems I know
about in my books are now listed online.

Also, you can now find a PDF copy of my November 2002 CUJ article, "Class
Template, Member Template -- or Both?" at
http://www.aristeia.com/Papers/CUJ_Nov_2002.pdf

Enjoy!

Scott

[New EC++ Errata Entries]

DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
10/12/02 bj 12 Clarify whether the "ISO/ANSI sanctified version
of C" I refer to in the book is now C99, not C89.

4/10/03 wk 77 The final bullet point on the page is misleading.
C++ imposes constraints on how copy constructors
behave, so rather than writing that a copy
constructor defines what it means to pass by
value, I should say that it defines how an
object is passed by value.

10/20/02 kk 125 In final sentence of 2nd-to-last paragraph,
clarify that callers must use the array form of
delete.

9/26/02 mh 127 It would be better if someFamousAuthor returned
a const String instead of just a String. This
would be consistent with the advice of Item 21.

10/12/02 bj 135 In first para, note that the "C philosophy that
variables should be defined at the beginning of
a block" is for C prior to C99.

! 10/12/02 bj Item 41 The first design problem includes the ability to
create "stacks of stacks of strings," but the
given solution has a private copy constructor,
making it impossible to create a Stack of Stacks.

This is fine (except for the const return type :-}), as
long as you make clear that this approach may be
needlessly expensive. For example, if all your data
members are of built in types, their assignments can't
throw, so doing swaps instead of assignments just burns
cycles needlessly. For large objects, you're talking
about duplicating an object's contents on the heap in
order to be able to perform the non-throwing swap.
There's nothing wrong with that, but my experience has
been that people advocating this approach to implementing
operator= often overlook the cost that it incurs. It's
exception safe, but it's often not cheap.

12/30/02 ma Item 19 It's true that virtual functions must be members, but one
can get virtual-acting behavior by having a non-virtual
function (possibly a non-member) call a virtual function.
This can be especially useful for functions like operator<<,
which must be non-members but can be made to act virtual by
internally calling a virtual function, e.g., one named
"print" or "write".

2/17/03 dys Item 19 Regarding the last bullet on page 88, dys writes:

The same rule should be used for other operators that
require a different class as a left-hand operand. For
example, CORBA uses "Any <<= Type", and for all classes
besides Any, operator<<=(T) is a non-member. I propose
the following change to your algorithm. Instead of

else if (f is operator>> or operator<<)

write

else if (f is an operator and needs another class as
its left-hand operand)

6/15/02 sdm Item 33 Randy Meyers (no relation) has a nice article on inlining
in C99, including an explanation of how the C99 rules differ
from those in C++, in the July 2002 issue of theC/C++Users Journal.

10/13/02 ya Item 36 ya writes: "Nonvirtual functions may call other functions
which are virtual. In that case, derived classes are indeed
presented with mandadory implementation, but only in the
highest, close-to-the-surface level. By overriding virtual
functions, the overall behavior of the nonvirtual function
can change in derived classes. Such usage of nonvirtuals is
very useful and is the basis for the 'template method'
design pattern."
This is true, but it's important to note that the
externally observable behavior of any function is defined by
its specification (i.e., it's interface), not by its
implementation. A nonvirtual implemented using template
method may behave differently for different derived classes,
but its behavior is still bounded by its specification.
Callers don't care whether the function is virtual or
nonvirtual. All they care about is that the function they
call exhibits the behavior its specification promises.
For implementers of derived classes, it's a different
story. They care very much about whether a base class
function is virtual or nonvirtual, because that affects what
they are allowed to vary. In Item 36, my remarks are
focused on the relationship between authors of base and
derived classes, not on the relationship between authors of
a class and clients of that class.

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:

Note that the second while loop is essentially a variant ofremove_if (see Item 32).

jr reports that in simple tests he performed comparing theperformance 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 associativecontainer (especially a map or multimap), it's important topass the correct comparison function. The easiest way to dothis is to pass the result of the value_comp memberfunction:

This works for sets and multisets, too, because for thosetypes, value_comp returns the same thing as key_comp.However, as noted in Item 44, for operations likelower_bound, etc., it's generally better to use memberfunctions instead of algorithms when both are applicable.

2/20/03 fr 156 Because postincrement is less efficient thanpreincrement, the if statement may be betterimplemented as follows:

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

2/26/03 shh 159 In order to make sure that the initial summary valuepassed to accumulate is of the appropriate type, shhsuggests using this form:

Y sum = accumulate (begin, // acts like a T*end, // acts like a T*static_cast(initValue) // initValue need not be of typeY);

DATEREPORTED WHO PAGES WHAT-------- --- ----- ------------------------------------------------8/14/02 sdm 66-67 The inheritance-based conversions described onthese pages apply only to public inheritance.For non-public inheritance, things get a bit morecomplicated. For details, including a rationalefor the behavior, consult the July 2001 CUJcolumn by Jim Hyslop and Herb Sutter,target="_blank">"Baseless Exceptions."

1/ 6/03 ais 67 In the examples near the top of the page, itwould be good to note that catch-by-value canlead to the slicing problem, a topic that isdiscussed on page 70 in Item 13.

Wednesday, March 19, 2003

I'm beginning to work on the third edition of Effective C++. The secondedition was a fairy conservative sprucing up of the original, but for thethird edition, I expect to make more extensive changes.

I constrained the second edition to follow the Item breakdown of the firstedition fairly closely, but this time I plan to start with a reasonablyclean slate and ask myself, "What are the 50 most useful pieces of advicefor professional developers NOW?" Without a doubt, some of the currentItems will make the cut, but it's time to include new topics, almostcertainly including design and implementation in the presence of templates;dealing with issues related to exception safety; the impact of threading,etc. At the same time, I want to continue to avoid undue overlap among mythree books, so there's little chance I'll devote significant space totopics I already treat in More Effective C++ or Effective STL.

I'll also maintain what I consider to be fundamental strengths of the book:Items that are short, specific, to the point, and that take both theStandard and real compilers/libraries into account.

I have plenty of ideas on what EC++/3E should contain, but I'm hopingyou'll offer suggestions, too. What Items or parts of Items are no longerneeded? What new topics should be addressed? What did I do right that Ishould avoid breaking? What needs fixing? Are there any things I did ordidn't do in More Effective C++ or in Effective STL that I should be sureto copy or be sure NOT to copy? Are there ideas from other books I shouldsteal? In short, how can I make EC++/3E the best EC++ ever?

I hope to receive a lot of email in response to this message, so pleasedon't be offended if all you get is a pro forma reply. I have only so muchtime and energy, and I hope we agree that it's more important for me towork on the book than to send everybody a personalized reply to eachsuggestion. Actually, if you squint just right, you can think of therevised book as a personalized reply to each of you, because I'll take allyour feedback into account as I work on it.

If would be most convenient for me if you'd send all suggestions toEC++3E@....

Friday, February 7, 2003

I've recently developed two new C++ seminars and added descriptions of them
to my web site. Currently, they are available only for on-site
presentations, though it would not surprise me if I end up presenting one
or both at open-enrollment seminars in Germany in September.

PATTERNS AND POLICY-BASED DESIGN. I've been getting a lot of inquiries
about design patterns recently, but it seems that few people know that
C++ is uniquely capable of generating flexible and efficient pattern
implementations. This seminar is my way of covering the patterns
material people want to know along with the C++ design techniques they
need to know in order to really exploit patterns in C++. As far as I
know, there's no other course like this, and I'm very excited about it.
I taught it for the first time last week, and it was a big hit.
Full Description: http://www.aristeia.com/patterns-and-pbd_frames.html

EFFECTIVE C++ IN AN EMBEDDED ENVIRONMENT. I mentioned the imminent
arrival of this seminar in a mailing last September, and I'm pleased to
say that it's now fully here. I'm even more pleased to report that the
embedded programmers who've attended the seminar have found the material
to be well suited to the concerns they confront. Short on bytes, cycles,
or a conforming C++ compiler, yet still want to take advantage of C++'s
modeling power, flexibility, efficiency or availability of outside tools?
Ask me how!
Full Description: http://www.aristeia.com/c++-in-embedded_frames.html

I also have a bunch of new talks I need to add to my Short Courses page
(http://www.aristeia.com/short-courses_frames.html). When I get them
added, I'll let you know.

Tuesday, February 4, 2003

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 thepage, as points out that "only the assigmentoperator is 'unnecessary', a temporary Widget isgoing to be constructed anyhow, so you have inbalance a (useless) construction/destructionplus an assigment OVER a (useful)construction/destruction.'

9/25/02 pn 171-172 Some examples here fail to explicitly state thatinheritance from e.g., std::binary_function ispublic. This is inconsistent with what I doelsewhere in the book, e.g., on pp. 178-179. Ishould check all the examples to make sure I'mconsistent.

DATEREPORTED WHO PAGES WHAT-------- --- ----- -----------------------------------------------------------7/15/01 sdm Item 1 For another discussion of the pros and cons of differentcontainers, check out Andrew Koenig's and Barbara Moo'scolumn, "Which Container Should I Use?," in the August 2001C/C++ Users Journal

8/26/02 sdm Item 7 Several people have written to ask about whyDeleteObject::operator() takes a pointer to const, eventhought it's going to delete the pointer. The answer isthat if I did not, it wouldn't be possible to useDeleteObject on containers such as vector.There has been much debate in the C++ community overwhether deleting pointers-to-const should be legal, but itis and it can be useful, so it's important to me thatDeleteObject support it.

9/ 4/02 ga 133 Writes ga, "Another variation: reserve, move away/copy theelements that would be moved one by one in one chunk andthen transform on the gap that we are left with." Ibelieve that in some cases, this will be more efficientthan 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.