Updated errata lists; article in CUJ; upcoming seminar reports

Topics this time:
- EC++ and MEC++ Errata Lists have been updated.
- I have an article in the October CUJ.
- Reports from "THE C++ Seminar" to be posted (but not here).


Updated Errata Lists:

I just finished updating the errata lists for Effective C++ and More
Effective C++. (Both books are due for reprints later this month, so the
time was ripe.) New entries to the errata lists are at the end of this
message. The full lists are available at the usual URLs:

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


Article in the October CUJ:

The October CUJ contains a slightly-modified version of Effective STL's
Item 43, "Prefer Algorithm Calls to Hand-Written Loops." (The article
title is one of the things that is slightly modified compared to the book.)
As an aside, the December CUJ is slated to run ESTL Item 45, but don't
believe it until you see it, because publication plans have been known to
change at the last minute.


Reports from "THE C++ Seminar":

The special C++ Seminar hosted by me, Herb Sutter, Dan Saks, Steve
Dewhurst, and Andrei Alexandrescu runs next Monday-Wednesday. If you're
one of the people who would have liked to attend, but couldn't, or if
you're just curious about what such an event will be like (I am), we plan
to post daily informal summaries to the seminar's mailing list. (They will
NOT be posted to this list). You can sign up for the seminar's mailing
list at http://groups.yahoo.com/group/cpp_seminar/.


Finally, I truly hope that you and yours were not personally affected by
Tuesday's indescribable horrors. Words do not exist for how I feel, so
I'll just say this: I wish you all the best.

Scott

===============================================================================
New Entries for the EC++ Errata List
===============================================================================
DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
3/ 7/01 das xix "Dave Smallberg" ==> "David Smallberg" 9/10/01
254

! 8/25/00 pm 68 In operator=, "*ptr = *rhs.ptr;" ==> 9/10/01
"ptr = rhs.ptr;" Modify the comment
accordingly.

8/15/00 cb 104 Eliminate the first prose paragraph on this page. 9/10/01
105 (When I originally wrote the paragraph for the
first edition of EC++, the example involved
string objects, not rational numbers, and for
strings, the situation was different. When I
changed the class for the example, I failed to
recognize that the words no longer made sense
for the example.) To avoid too unbalanced a
page, I moved the break between pages 104 and 105.

8/16/00 cb 124 At the end of the 2nd to last sentence on the 9/10/01
page, it would be helpful to xref Item 21's
explanation that the data pointed to by a pointer
in a const object is not automatically const.

! 2/10/00 ic 212 A class declaring no operator& function(s) 9/10/01
cxh 213 does NOT have them implicitly declared. Rather,
245 compilers use the built-in address-of operator
246 whenever "&" is applied to an object of that
type. This behavior, in turn, is technically
not an application of a global operator&
function. Rather, it is a use of a built-in
operator.
I eliminated mention of operator& as an
automatically generated function and adjusted the
index to eliminate entries for the removed
material.

! 4/ 8/01 hs 228 The Standardization Committee has now ruled that 9/10/01
library implementers must declare string as
defined in the Standard, so my comment about
their being allowed to add extra parameters is
incorrect. However, the Standard continues
to forbid you from declaring string yourself.
The advice in this Item stands (#include
<string> instead of trying to declare the string
type yourself), but the rationale for that
advice is no longer valid.

Interesting Comments:

DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
8/ 8/00 cb 15 Observes cb:

It appears that the Microsoft Visual C++ 6.0 SP3 compiler
requires the "enum hack" to work. Interesting, since it
is stated that "Unless you're dealing with compilers of
primarily historical interest (i.e., those written before
1995), you shouldn't have to use the enum hack."

It appears that Visual C++ 6 was released in mid-1998.
Sigh.

6/20/01 cbs Items cbs points out that the code in Item 30 isn't thread safe,
sdm 7,8,10 but the problem exists in Items 8 and 10, too. In fact, I
fail to consider thread-safety throughout the book,
something I can argue is excusable only because C++ itself
fails to consider threading issues. You'll see other
comments on how threading interact with my advice in
various places in this errata list. If I ever write a
third edition, I'll be sure to take threading issues into
account.

6/ 5/01 sdm 67 In the prose following the third code example, it's not
technically true that the temporary is const. Rather, the
temporary is an rvalue, and C++ forbids binding references
to rvalues unless they are references to const. This is
not a bug in the book. Rather, it is a deliberate attempt
to spare you from having to know about rvalues, because
they're more confusing than helpful, especially if you know
the rules for rvalues in C. Setting aside technicalities,
the information on this page is accurate in its
essentials.

6/22/01 sdm Item 19 The bulleted summary at the end of this Item no longer
reflects my full thinking on this topic. For an updated
version of the summary as well as an explanation of how and
why things changed, please read my February 2000 href="http://www.cuj.com/" target="_top">C/C++
Users Journal article, href="http://www.cuj.com/articles/2000/0002/0002c/0002c.htm" target="_top">"How
non-member functions improve
encapsulation."

2/19/01 sdm Item 19 When templates enter the picture, things become more
complicated. Compilers must not only perform type
conversions on actual parameters, they must also perform
template type deduction to determine the types of formal
parameters. The end result is that templates for functions
like operator+ should still be non-members, but they need
to be defined as friends inside the class they work with in
order to be instantiated correctly. For details, consult
the February 2000 thread in comp.std.c++ with the title,
href="http://groups.google.com/groups?hl=en&safe=off&threadm=zdv176.950799804%40\
zam475&rnum=1&prev=/groups%3Fas_epq%3Dautomatic%2520conversion%2520with%2520func\
tion%2520templates%26as_ugroup%3Dcomp.std.c%252b%252b%26as_drrb%3Db%26as_mind%3D\
29%26as_minm%3D1%26as_miny%3D2000%26as_maxd%3D5%26as_maxm%3D9%26as_maxy%3D2001%2\
6num%3D100" target="_top">"Automatic conversion with function templates?"
It was
initiated by Bernd Mohr.

9/17/00 ch Item 20 Notes ch:

Objects are state machines. An Object would lose control
of its own states if you allow public data members. This
makes it for instance impossible to implement a typical
Observer Pattern in an object oriented way. The problems
get really nasty for objects with public data members
when living in a multithreaded environment ....

6/11/00 tm 99 In general, it's dangerous for a function to return a
reference to a parameter passed by reference-to-const,
because the parameter may have been bound to a temporary
object that will be destroyed at the end of the call. For
example, consider this use of returnStudent:

Student makeStudent(); // function declaration

const Student& cs = returnStudent(makeStudent());

returnStudent's parameter s is bound to the temporary
object returned from makeStudent. returnStudent then
returns that reference, which is used to initialize another
reference, cs. Unfortunately, once cs is initialized, the
temporary returned from makeStudent is destroyed, and cs is
a dangling reference -- it refers to an object that no
longer exists. (Note the similarity to the problem
discussed on pages 127-128.)

2/27/01 ph Item 23 Once you've resigned yourself to returning a new object
from functions like operator*, you'll naturally look for
ways to make that as cheap as possible. One way to do that
is to return a pointer posing as an object.
The following comment was sent regarding Item 20 of href="http://www.awl.com/cseng/titles/0-201-63371-X/" target="_blank">More
Effective C++, but it's relevant to Item 23 of
Effective
C++, too:

We faced the problem of getting large float and int
arrays from a database. The dimension of the array
depended on the time interval passed as an argument to
the reading method. Clearly, we had to return an object,
and we couldn't rely upon return value optimization
[which is the subject of MEC++ Item 20].

Our solution was to return an auto_ptr<Array<T>
> instead
of an Array<T>. This way, we had the advantage of
returning something as light as a pointer without the
problem of potential memory leaks. The only drawback was
a slightly heavier syntax but it was worth it.

I don't think this is a solution for the method operator*
that you used in item 20 but many other methods that have
to return large objects may benefit from it.


===============================================================================
New Entries for the MEC++ Errata List
===============================================================================
DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
3/30/01 sdm 2 Material in the book is based on the final C++
Standard, not the DIS.

9/ 6/00 bp 33 In accord with my advice in Item 21 of Effective
C++ to "use const whenever possible," oldValue
should be declared const in the code example at
the top of the page.

2/21/01 wds 58 In second paragraph, "initializationof" ==>
"initialization of".

! 8/15/00 wcm 142 For consistency with the changes I made on
144 6/6/98 (see above), the Counted template should
have objectCount return a size_t instead of an int,
and numObjects should be of type size_t, not int.

Interesting Comments:

DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
7/31/00 cw 208ff Notes cw:

While href="http://www.aristeia.com/BookErrata/M29Source.html"
target="_blank">exploring your reference counting code, I realized
that there is no method allowing a user of the RCIPtr
class to mark the CountHolder unshareable. I believe such
a method is essential to the correct operation of the
RCIPtr when a user is confronted with making a some one
else's class reference counted and that class has methods
which return references to the the internal parts of the
class.

In your widget example, if there were a method
int& Widget::getThat(), the corresponding RCWidget method
would have to make a call to a RCIPtr::markUnshareable()
method that would call the RCObject::markUnshareable()
method. This would prevent the int reference from being
used to alter a widget that is held by more than one
RCWidget.
http://www.aristeia.com/BookErrata/M29Source.html

2/27/01 ph Item 20 Writes ph:

We faced the problem of getting large float and int
arrays from a database. The dimension of the array
depended on the time interval passed as an argument to
the reading method. Clearly, we had to return an object,
and we couldn't rely upon return value optimization.

Our solution was to return an auto_ptr<Array<T>
> instead
of an Array<T>. This way, we had the advantage of
returning something as light as a pointer without the
problem of potential memory leaks. The only drawback was
a slightly heavier syntax but it was worth it.

I don't think this is a solution for the method operator*
that you used in item 20 but many other methods that have
to return large objects may benefit from it.


4/27/97 sdm Item 30 In a posting to comp.lang.c++.moderated posting of
4/25/97, Brian Parker writes:

One problem with the use of proxies that I have found that
is not discussed in "More Effective C++" is when they are
used for templated types e.g. for complex... . In
this scenario, when calling template functions that take
complex (e.g. conj() et al) with a returned proxy, the
proxy is not converted to a complex but instead a
template argument deduction failure results.

For further information on this observation, look up the
thread, href="http://groups.google.com/groups?hl=en&threadm=5jq51o%2479g%40netlab.cs.rpi\
.edu&rnum=1&prev=/groups%3Fas_epq%3Done%2520problem%2520with%2520the%2520use%252\
0of%2520proxies%26as_ugroup%3Dcomp.lang.c%252b%252b.moderated%26as_drrb%3Db%26as\
_mind%3D29%26as_minm%3D3%26as_miny%3D1997%26as_maxd%3D13%26as_maxm%3D9%26as_maxy\
%3D1997">"lvalue/rvalue, non-const/const" initiated by Daniel
Hempel on April 21, 1997.

8/ 5/01 sdm Item 31 For a more contemporary treatment of multiple dispatch
than I give in Item 31, check out chapter 11 of Andrei
Alexandrescu's excellent href="http://www.awl.com/cseng/titles/0-201-70431-5/">Modern C++
Design. It's the most
thorough and up-to-date examination of the topic that I know
of.

Updated ESTL Errata; Powell's Talk Reminder

Two quick things:
- I've updated the ESTL errata list. New entries are below.
- Reminder: I'm speaking at Powells in Portland this Thursday.

Updated ESTL Errata List:

I've received a number of interesting bug reports and other comments on
ESTL since I last updated the errata list, so I've added the new stuff to
the list. You'll find the updated list in its usual spot at
http://www.aristeia.com/BookErrata/estl1e-errata_frames.html. The new
entries are listed below in the half-baked form I use internally for
keeping track of new errata.


Talk at Powell's this Thursday:

This Thursday night I'll be doing a C++/STL Q&A at Powell's Technical
bookstore at 7:00 PM. For details, consult my earlier mailing on this
topic (http://groups.yahoo.com/group/scott_meyers/message/27). I hope to
see you there!


Scott


DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
8/31/01 ds iv "Dr. Suess" ==> "Dr. Seuss" (twice).

8/ 4/01 dg 18-19 Once the typedef WidgetContainer is introduced,
the variable vw should be renamed cw to reflect
the new, more abstract, type name.

8/23/01 sdm Item 4 Clarify that of the three list::splice functions,
only one requires linear complexity. The other
two can run in constant time and can allow size to
run in constant time.

8/17/01 sdm 47 Omit from para 2 the advice to treat list like
a sequence container. Based on a discussion with
jep, I'm now less certain that that convention is
as widespread as I'd thought.

! 8/16/01 kh 55-56 My discussion of putting containers in shared
memory is incomplete and, to some degree,
misleading. As Item 15 demonstrates, some string
implementations use the small string optimization,
so elements of such strings won't be in shared
memory unless the string objects themselves are.
Furthermore, even use of placement new to put
containers in shared memory won't put static
components of those containers in shared memory,
and the Standard allows containers to have such
components (e.g., a shared empty string
representation); some implementations take
advantage of this allowance. kh summarizes things
this way: "No matter how well-written your
allocator implementation [for shared memory], if
it works, it is either a matter of luck or
hardwiring to a specific container implementation."

! 8/23/01 ja 78-79 When string implementations use reference
counting, the swap trick doesn't decrease the
capacity, because the copy constructor isn't
allocating any memory; it's just adjusting a
reference count. A more reliable way to perform
shrink-to-fit is to create the temporary string
via the range constructor, e.g., like this for the
last line of code on page 78:
string(s.begin(), s.end()).swap(s);

8/23/01 ja 79 The last paragraph of Item 17 is true, but it
doesn't matter in this context, because the swap
is with a temporary object that is destroyed at
the end of the statement. As a result, all
iterators, pointers, and references into the
"shrunk-to-fit" string have been invalidated.
I'll omit this paragraph from future printings
(and I'll try to remember to check the index to
see if it gets anything from this paragaph).

7/31/01 gl Item 20 When your comparison function for an associative
container isn't less<T>, it's important to specify
the comparison function for all algorithms that
will perform comparisons. Include a warning in
this Item and xref the example on pg. 149 in
Item 34. Note that following the advice of Item 44
minimizes the chances of running into this kind of
problem.

! 8/22/01 sdm 92 Eliminate the second-to-last sentence on this
page. In fact, equal values *are* equivalent,
because neither of two equal values precedes the
other in any reasonable sort order. (The
definition of "reasonable" is "strict weak
ordering," as I mention on page 94.)

! 8/22/01 jep Item 22 Shortly after the book was published, the Committee
decided that elements of sets/multisets should not be
modifiable without a cast, so the second code example
on page 96 is now invalid. To change a set/multiset
element in place, use the const_cast technique shown
on page 98. If you don't need in-place modification,
the five-step process described on pp. 99-100
continues to be safe and portable.

! 8/22/01 jep 104 In the lines after the calls to lower_bound, the
106 second test should be "!(w < *i)" and
"!(s < i->first)", respectively. This needs to be
fixed in both the code and the comments.

! 8/20/01 ag 108 The analysis for the cost of the call to insert is
incorrect, because it overlooks that the pair
created in the insert call is a temporary that
will ultimately be used to copy construct the pair
stored in the map. Because the temporary pair
contains a Widget, a temporary Widget is
constructed and destroyed. In practice, ag
observed that "the difference between the two
methods is only that in the operator[] form,
there's the extra call to the assignment operator
specialized for a double."
ag has demonstrated that operator[] could be
implemented much more efficiently than insert, but
the Standard is unfortunately worded in a way that
makes such implementations illegal. In the
future, this wording may be changed, or
implementers may choose to ignore it.
All things considered, the conclusion that insert
is more efficient than operator[] when adding new
elements to a map is not as reliable as I thought
when I wrote the book. In the immortal words of
Nathan Myers, "if it matters, measure."

8/ 4/01 dg 136 In last para, "which reorders element" ==>
"which reorders elements".

8/23/01 sdm 144 In the lower diagram, non-code text in
"remove_if's return value" should be in text font.

! 8/16/01 kh 159 In the call to accumulate at the top of the page,
the literal 0 is incorrect. Because its type is
int, accumulate will use int as its internal type
for storing the partially accumulated sums. The
correct type for this is string::size_type. It
makes a difference, because int is signed and
string::size_type is unsigned.

8/ 3/01 sdm 160 In the para following the code, there should be
no line break between "paragraph" and "2".

8/ 4/01 dg 162 The use of the term "components" in the 1st para
is confusing, because I never define that term.
Reword. (In general, I use "component" in this
book to mean "something in the STL.")

8/21/01 sdm 165 BPFCImpl should inherit from unary_function.

8/24/01 sdm 169 Practically speaking, anotherBadPredicate isn't as
bad as the function objects generated by
BadPredicate, because there is only one copy of
its state. As a result, anotherBadPredicate is
likely to behave as expected when passed to
remove_if or any other algorithm. (But see below
for "Interesting Comments" on Item 39.)

8/18/01 sp 187 Once in a code example on each page,
188 "vector<int> iterator" ==>
189 "vector<int>::iterator".

8/23/01 sdm 200 In the entry for equal_range in the next-to-last
row of the table, add "(followed by distance)".
Make the same change to this table on the book's
inside front cover.

8/30/01 ab 211 At end of 2nd para, "Another STL platform I uses..."
==>
"Another STL platform I use..."

8/ 4/01 dg 221 In 2nd para, "do fire up" ==> "do is fire up".

8/28/01 jtw 228 A more reliable URL for [27] is
http://www.research.att.com\
/~bs/stack_cat.pdf.


Interesting Comments:

DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
7/28/01 jep Item 9 The approach I show for erasing elements in a contiguous-
memory container while iterating through it does a good
job of maintaining iterator validity, but the time
complexity of the approach is quadratic. This can
typically be improved to linear by using a two pass
strategy:
1. Walk the container, writing the log for each element
you plan to erase (but don't erase anything yet).
2. Perform a range erase, e.g., by using the erase-
remove idiom or by using partition (or
stable_partition) and then erasing.

8/19/01 hxh 72-73 Regarding Implementation B's capacity being 7 when the
size of the string is 5, hxh (the author of
Implementation B) writes:

At the time I wrote , I could not imagine an
allocator that could deliver a non multiple of
sizeof(void*) bytes on the platforms I was targeting. I
could imagine specialty allocators that could very
efficiently deliver 4 bytes, but not 1, 2 or 3 bytes.
Or 8 bytes, but probably not 5, 6 or 7. So string takes
advantage of this. If the client asks for 5 bytes, he
gets 7 (8 minus 1 for the terminating null). So this
string really does have a minimum capacity. It's 3. I
tend to go for very small minimum capacities in order to
make containers of containers more efficient.

8/ 4/01 sdm Item 23 As part of the Loki library described in his book,
Modern
C++ Design (Addison-Wesley, 2001), and downloadable
from the book's web site, Andrei Alexandrescu developed the
AssocVector template, a map-like container built on top of
sorted vectors. If you're interested in the performance
improvements you might get from using a sorted vector
instead of a map, consider downloading AssocVector and
giving it a try.

8/20/01 ag 110-111 Write ag:

The discussion about using a generic ValueArgType to use
the specialized assign if present is interesting, but
using KeyArgType instead of key_type may trigger
multiple conversions for the key. Imagine having a map
indexed by strings and calling

efficientAddOrUpdate(m,"Andrea",10.5);

With the version in the book there are three conversions
from KeyArgType to key_value: one in lower_bound, one in
key_comp and another one in insert.

8/ 3/01 yjz Item 37 Writes yjz:

I agree that accumulate most clearly expresses what's
going on. Personally, that's more intuitive to me. I
would definitely choose accumulate when I do simple
value accumulations. But for the final example in this
item, I would definitely use for_each because the
solution using accumulate provided by this item
introduces a lot of overhead by calculating the average
point every time the operator() is called. So,
supposedly, we have n elements in the container, for the
example using accumulate, you will calculate the average
of points n times. But in for_each example, you only do
that calculation once. For this specific example, there
are 2*(n-1) times of division and (n-1) times of
construction of temporary Point objects which are not
necessary.

8/24/01 sdm Item 39 My decision to advise readers to make predicates pure
functions was based on pragmatic considerations, not on
the Standard. In fact, Kreft and Langer argue in their
April
2001 CUJ column that the Standard allows
predicates to have state, though they concede that the
problem I describe in this Item does exist in some STL
implementations. The Committee is aware of the problem,
but from what I can tell, they are leaning towards
modifying the Standard to require that predicates be pure
functions. If they do, my advice will conform to the
Standard at that point. To follow the Committee's
deliberations on this matter, monitor the status of
Library
Working Group Issue #92.

6/16/01 al Item 39 The idea of using remove_if to eliminate the third element
from a range is 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 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 the third element visited
would be removed; we wouldn't be able to make any
assumptions about WHICH element that would be. For more
on this idea, consult the April 2001 column by
Klaus Kreft and Angelika Langer, "Unary
Predicates
in the STL." At the same time, it's worth noting that
every implementation of remove_if I know behaves like the
one in the book, and there are technical reasons why
alternative implementations are unlikely.

8/16/01 kh 203 Strictly speaking, the code at the bottom of this page
is not standard-conformant, because library implementers
are permitted to add extra parameters to library
functions, as long as the parameters have default
values. (You can read about this matter in Herb
Sutter's GOTW
#64.) A workaround for such a perverse
library implementation would be precisely what Item 46
suggests: use a function object to wrap the call to the
library function.

Appearance Sept. 6th in Portland, Oregon

Addison-Wesley has scheduled me for an "author event" in Portland, Oregon:

Powells Technical Bookstore
33 NW Park
Portland, Oregon

Thursday, September 6
7:00 PM

This will be an open-ended Q&A session on anything in my books, my
articles, my newsgroup postings, or anything else in the world of C++. Or
my dog. In case there are no questions for me, I'll bring questions for
you :-)

I hope to see you September 6th at Powell's in Portland.

Scott

June CUJ Article is now Online

My June CUJ article, "Three Guidelines for Effective Iterator Usage," is
now available in PDF at my web site:
http://www.aristeia.com/Papers/CUJ_June_2001.pdf.

Scott

Updated ESTL and CD Errata Lists

I've just posted updated errata lists for Effective STL and the Effective
C++ CD. You'll find the updated lists at the usual places:

ESTL: http://www.aristeia.com/BookErrata/estl1e-errata_frames.html
EC++CD: http://www.aristeia.com/BookErrata/cd1e-errata_frames.html

The list for the CD hasn't changed much. The list for ESTL has.

I hope to update the errata lists for Effective C++ and More Effective C++
later this month.

Scott

Last call for "THE C++ Seminar"

"THE C++ Seminar" (http://www.gotw.ca/cpp_seminar/) featuring me, Herb
Sutter, Dan Saks, Andrei Alexandrescu, and Steve Dewhurst sells out at 85
attendees. There are now about 10 spots left, and we can't increase the
limit, because the hotel has no more room. (I know, because I called them
today.)

If you've been thinking about attending the seminar, I encourage you
to register immediately.

Thanks,

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

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/
+---------------------------------------------------+

Error in Seminar Dates; Free ESTL for past Seminar Attendees

Two very quick things:
- I got the Zurich seminar dates wrong.
- Attendees of my earlier STL seminars get a free copy of ESTL.

In my last mailing, I bungled the dates for my seminar in Zurich. The
correct dates are at my web site. Rather than run the risk of getting them
wrong here again, here's the link to my seminars page:
http://www.aristeia.com/seminars_frames.html. I apologize for the error.

If you attended one of my STL seminars last June or this past January,
you're entitled to a free autographed copy of ESTL. If you haven't
received email recently asking for your current mailing address, it's
because our email to you bounced, and we don't know how to get in touch
with you. If you were a seminar attendee and you haven't heard from us,
please send your current mailing address to nancy@.... That's my
wife, so be nice to her :-)

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

Upcoming Seminars in Europe and Japan; ESTL Sale

Two topics:
- Seminars scheduled for Zurich, Stuttgart, Berlin, and Tokyo
- ESTL on sale at 40% off


SEMINARS

I've recently scheduled fall seminars in Switzerland, Germany, and Japan.
In particular:
Zurich, Switzerland September 17-19
Stuttgart, Germany September 24-25
Berlin, Germany October 1-2 and 4-5
Tokyo, Japan November 13-16
You'll find details at my seminars page,
http://www.aristeia.com/seminars_frames.html. At that same page you'll
find a link to "THE C++ Seminar," which I mentioned in an earlier mailing.
The more we work on it, the better I think that seminar is going to be.
It's currently about 1/3 subscribed, so if you're interested in attending
(and I hope you are), I encourage you to register sooner than later.


EFFECTIVE STL ON SALE

Both Amazon.com and BooksAMillion.com are currently offering Effective STL
for $24, which is 40% off. As an author, my discount when buying the book
is only 35%, so I think this is a pretty good deal! If you've been
thinking about buying the book, I think this is a good opportunity to get
it for cheap. To preview the content in ESTL, check out my article in the
June C/C++ User's Journal as well as the four sample Items you'll find at
AW's site for the book, http://www.aw.com/cseng/titles/0-201-74962-9/.

If you decide to buy the book from Amazon, please consider going to Amazon
via the following link, because I get a small kickback if you do. (Your
price remains unchanged.)


http://www.amazon.com/exec/obidos/ASIN/0201749629/o/qid=987984055/sr=2-2/scottme\
yersho-20

Thanks,

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

Reminder: Template Workshop Submissions due June 15

This is a reminder that submissions for this year's Workshop on C++
Template Programming (to be held in conjunction with OOPSLA in Tampa Bay,
Florida in October) are due on June 15. For details, please consult
http://www.oonumerics.org/tmpw01/.

I'm on the Program Committee for this event, and last year's workshop drew
some really outstanding papers. (Check out http://oonumerics.org/tmpw00/
to see what I mean.) If you're doing interesting work with C++ templates,
I strongly encourage you to share your ideas with the rest of us. Help make
this year's Template Workshop even better than last year's!

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

ESTL Sample Items Now Available

Addison-Wesley has made four sample Items from Effective STL available
at the Effective STL web site,
http://www.awl.com/cseng/titles/0-201-74962-9/. You'll find links to the
Items in the navigation area of that page, or you can use the following
direct links:

Item 2: http://www.awl.com/cseng/titles/0-201-74962-9/item2-2.pdf
Item 16: http://www.awl.com/cseng/titles/0-201-74962-9/item16-2.pdf
Item 21: http://www.awl.com/cseng/titles/0-201-74962-9/item21-2.pdf
Item 44: http://www.awl.com/cseng/titles/0-201-74962-9/item44-2.pdf

I hope you enjoy these sample Items.

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

DDJ Video Interview; ESTL Sample Items

Two quick things:
- Dr. Dobb's video interview with me is now on-line.
- Update on appearance of ESTL sample Items.

VIDEO INTERVIEW:

When I was at the Software Development Conference last month, Dr. Dobb's
roped me into a short interview for technetcast, and that interview is now
available. If you'd like to know what I had to say (nothing profound), or
if you'd just like to know what I look/sound like (after being compressed
for distribution over the net), surf on over to
http://technetcast.ddj.com/tnc_play_stream.html?stream_id=543.


ESTL SAMPLE ITEMS:

I'm not sure why, but the excerpts from Effective STL that were supposed to
start appearing at the book's web site on May 14 aren't available yet. We
still plan to put four sample Items up, but I don't know exactly when it
will happen, but I'm assured it will be soon. I do know the Item numbers
that will appear, however: 16, 44, 21, and 2, in that order.


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

THE C++ Seminar

If you're in a hurry, this is all you need to know:

THE C++ Seminar: 3 Days with 5 Experts
Scott Meyers, Herb Sutter, Dan Saks, Steve Dewhurst, Andrei Alexandrescu
September 17-19 in Portland, Oregon
http://www.gotw.ca/cpp_seminar

What follows is more information about this remarkable event.

* * * * *

Wouldn't it be fun, I thought, to get together with some of the best C++
authors, consultants, and lecturers, and have a party? I'm talking about
the people I turn to myself when I have questions about C++ software
development. People who are undisputed experts. People who are
undisputably articulate. People who are undisputably fun. People who I
almost never get to see, because we're all traveling all the time, and even
when we show up at the same event, we're almost always scheduled to speak
opposite one another. Wouldn't it be fun to get them together in the same
room for a few days to talk about anything and everything related to C++?
To have a chance to learn from one another? To have a chance to heckle one
another and challenge one another? I thought it would be HUGE fun.

So I approached Herb Sutter, Dan Saks, Steve Dewhurst, and Andrei
Alexandrescu, and I asked them if they'd like to do it. I was pleased when
they said they would. I was even more pleased when we managed to find
three days this fall when all of us were available. Thus was born what we
call "THE C++ Seminar: 3 Days with 5 Experts." It's a party with an
unmatched technical program. And you're invited to participate.

The five of us each know more about C++ than is probably healthy, but
individually we also have unique strengths. Herb, for example, knows all
about distributed computing, distributed databases, and other things
distributed and concurrent, because that's been his application area for
years. Dan's foundation in C and C++ standards is unparalleled, and his
knowledge of the embedded market is, well, let's just say there's a reason
he's a columnist for Embedded Systems Programming magazine. Steve used to
work with Bjarne on C++ compilers. Yes, that Bjarne. You want to know
what's going on inside a compiler? We can all guess, but Steve's guesses
are likely to be especially good, because he's had to implement compilers.
Andrei has *forgotten* more about C++ templates than the rest of us are
ever likely to know. And me? It was my idea, so they had to let me
attend.

We're still fine tuning the details of this event, but we know this for
sure:
- Unlike the conferences and trade shows where we sometimes speak, each
of us will be at this seminar all the time, so you can easily track us
down to talk to us about whatever you want to. Saw something in one of
our books that confused you? Make us clarify it. Disagreed with
something we said in a presentation:? Make us defend it. Want to know
why we're not doing Java? Ask us.
- The seminar topics aren't limited to C++ per se. Related technologies
are on the table, too. Threading, patterns, embedded and distributed
systems, dynamic linking, template-based generic and generative
programming, they're all fair game. This isn't so much a seminar on
C++ as much as a seminar on using C++ to get your jobs done. We all
claim to be consultants. Demand some useful consultations.
- The material here will be intermediate, advanced, or better. There
won't be any superficial introductory talks.
- We hope to do some joint presentations, because many of us have strong
feelings about some topics, and those feelings aren't always in
agreement. For example, I know that some of the other speakers are
more enthusiastic about exceptions than I am. In some cases, our
interests in a single topic approach it in quite different ways.
For example, Herb, Andrei, and I have all written about the standard
string type, but our takes on it have been dramatically different.
Who knows, maybe we'll get lucky, and a fight will break out.
- The seminar won't be hands-on, but you're welcome to bring a laptop and
throw our sample code against your compilers. You're also welcome to
bring problematic code and ask us to look at it. Just remember that
we're not under NDAs, and we might ask for permission to show some of
your code in a seminar presentation.

Registration for THE C++ Seminar will open soon. You can join the seminar
mailing list to be notified about registration and seminar details at least
one week before the general public. Space for this event is limited (really
-- the hotel has physical limits), and those who are on the seminar mailing
list will be the first to be informed when registration begins.

You can join the seminar mailing list via the box on the seminar web page
(http://www.gotw.ca/cpp_seminar), or by sending mail to
cpp_seminar-subscribe@yahoogroups.com.

I know this seminar is going to be great fun. I'm already thinking of
questions to spring on Herb, Dan, Steve, and Andrei. I encourage you to
think of your own questions, then join us in Portland September 17-19.
It's a party. It's an event. It's THE C++ Seminar.

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

PDF for ESTL TOC is now available

PDF for the ESTL TOC is now available in the "Files" section of this
mailing list's web site. The URL for the TOC is
http://groups.yahoo.com/group/scott_meyers/files/Standalone%20TOC.pdf.

Scott

ESTL in CUJ, etc.

Three short announcements:
- The June CUJ with an ESTL excerpt now exists (for me)
- Buy ESTL from Amazon via my special link, and I get a kickback...
- Bruce Eckel's hands are on C++ again


Today I received my author's copies of the June C/C++ Users Journal. The
first article is from Effective STL and is entitled "Three Guidelines for
Effective Iterator Usage." The material in the article is a thinly-edited
version of the book's Items 26-28. Authors' copies of the magazine tend to
arrive before subscribers' and before the magazine shows up on newsstands,
so figure it will be around a week or so before the magazine is widely
available. In the meantime, you can view the cover and TOC of the June CUJ
at http://www.cuj.com/current/index.htm?topic=current. At some point in
the future, my article will be available online, but I don't know when that
will be.

* * * * *

If you're planning to buy a copy of ESTL from Amazon, please consider using
the link from my book page. My motive? I get a kickback from Amazon for
books ordered via those links. (Your price is the same either way.) My
books page is http://www.aristeia.com/books.html.

In a hurry? Skip the trip to my site and just use this:


http://www.amazon.com/exec/obidos/ASIN/0201749629/o/qid=987984055/sr=2-2/scottme\
yersho-20

* * * * *

Bruce Eckel, friend to me and to all programmers everywhere, has asked me
to announce the following:

Chuck Allison will be teaching Bruce Eckel's "Thinking in C++" Hands-on
Seminar in beautiful Crested Butte, Colorado, June 25-29. Chuck will
cover the matrial in Volume 1 of the Second Edition of Bruce's "Thinking
in C++". To learn more or sign up, visit
http://www.mindview.net/Seminars/ThinkingInCPP/. Bring your mountain bike
and hiking shoes (and a jacket).

Unlike me, Bruce doesn't release his books in dribs and drabs. You can
download complete snapshots in one swell foop. Feel like fooping? Visit
http://www.mindview.net/Books. No mountain bike required.

That's it for now. Stay tuned to this mailing list, because more ESTL
Items will be available in the coming weeks. I'm also going to post a PDF
copy of the book's TOC one of these days, because the preliminary one at
http://cseng.aw.com/book/toc/0,3830,0201749629,00.html is incorrect.
That's not AW's fault. At literally the last minute, I changed the title
of Item 36 to more accurately reflect the material it covers. It's still
about copy_if, but its advice is to NOT implement it via remove_copy_if and
not1. Those of you at my talk in Bellevue last night know what I mean.

Scott

Effective STL is done! Sneak Preview next Monday...

Yesterday I send Addison-Wesley a completed copy of my next book,
"Effective STL." The book won't physically exist for about a month, and it
will probably be about mid-June before it shows up in local bookstores, but
between now and then you'll have ample opportunity to get a flavor for the
book, because we're making a whole slew of Items available. The June CUJ
will contain an excerpt, as will the July DDJ. AW will be posting one
sample Item per week for four weeks starting in mid-May. I'll provide more
details on all of those things as they occur, but if you live near
Bellevue, Washington, you can get a glimpse of the book before anybody
else, because next Monday I'm presenting the following talk for WSA's
WinSIG:

When: Monday, May 7th, 2001
networking: 6:30pm, presentation 7:00pm

Where: Overlake Hospital Conference Center
121 107th Ave NE, Bellevue
NOTE: This is off Old Main Street and 107th
in Bellevue, not at the hospital itself. Take
Main Street and turn North onto 107th,
conference center will be on your left.

EFFECTIVE STL SNEAK PREVIEW

For the past 18 months, Scott Meyers has been exploring the STL, and he
just sent to his publisher the results of his efforts, the new book,
Effective STL: 50 Specific Ways to Improve Your Use of the Standard
Template Library. In this talk, Scott presents three Items from this
new book, items that focus on material not usually covered in
descriptions of the STL. He also hands out flyers for the new book and
urges everyone to buy their usual minimum of three copies: one for the
office, one for home, and one for each of your cars (for when you're
stuck in traffic).

Cost: Free! No reservations required. Invite your
friends!

FEEL FREE TO DISTRIBUTE THIS EMAIL TO OTHERS

PLEASE FORWARD TO YOUR COMPANY'S INTERNAL
DEVELOPER'S DISTRIBUTION LIST

I hope to see you next Monday in Bellevue.

Scott

2001 Workshop on Template Programming

Last year I helped organize a workshop on C++ template programming. It was
a big success, and we'll be doing it again in October, this time in
conjunction with OOPSLA. I hope you'll consider submitting a paper or
attending. Information and links are below.

Scott

---------------------------------------------------------------------------

CALL FOR EXTENDED ABSTRACTS

WORKSHOP ON C++ TEMPLATE PROGRAMMING
(http://www.oonumerics.org/tmpw01/)

Sunday, October 14, 2001
Tampa Bay, Florida, USA

in Conjunction with
OOPSLA 2001
(http://oopsla.acm.org/)


Some of the most exciting research in C++ focuses on the use of
templates, especially as a means to support generic and generative
programming. A number of powerful, flexible, and useful techniques
have been developed but these efforts appear isolated and are only
known to a few experts. This workshop will gather the community of
people interested in C++ template programming. The goal is dual:
first, to increase the visibility of information likely to be helpful
to other workers in the field of C++ template programming; second, to
clearly establish, and hopefully advance, the state-of-the-art in C++
template programming.

We encourage submission of extended abstracts of 7 to 12 pages on any
aspect of C++ template programming, including (but not limited to) the
following:
Generic and generative programming in C++
Uses or extensions of the STL or other templates in the standard
libray
Traits and traits-based programming
Iterators for multidimensional data structures
Template metaprogramming, including the representation of
metainformation in C++
Multiparadigm programming
Combining static configuration with dynamic techniques
Type-theoretic modelling of templates
Interaction of C++ templates with the object model
Expression templates
Experience reports on template programming
Debugging template code
Compiler support for templates, including compilation times and
diagnostics
Implementing C++'s template features
Portability issues
Template design and programming techniques

Our primary interest is in abstracts describing new work, but we will
consider abstracts based on prior publications. (Work that has already
been published should be identified as such.) One of our goals is to
increase the visibility of information likely to be helpful to other
workers in the field of C++ template programming.

As examples of suggested style and possible content, the accepted
papers from last year's (2000) Workshop can be found in:
http://www.oonumerics.org/tmpw00/


A workshop proceedings will be produced in electronic form, to be made
available via the Internet or on CD by the time of the workshop.


SUBMISSION GUIDELINES:

Extended abstracts (7-12 pages) should be sent to
tmpw01@.... Electronic submission in PDF is
strongly preferred. Questions about the submission process should be
sent to tmpw01@....


IMPORTANT DATES:
15 June Extended Abstract Submissions Due
30 July Notification of Accepted Submissions
30 August Final Extended Abstracts Due


PROGRAM COMMITTEE:
Andrei Alexandrescu, RealNetworks, Inc., USA
Matt Austern, AT&T Research, USA
Thomas Becker, Zephyr Associates, Inc., USA
Krzysztof Czarnecki, DaimlerChrysler AG, Germany
Ulrich Eisenecker, University of Applied Sciences,
Kaiserslautern, Germany
Nicolai Josuttis (co-Chair), Author and Consultant, Germany
Scott Meyers, Author and Consultant, USA
Mark Rodgers, Cadenza New Zealand Ltd, New Zealand
Yannis Smaragdakis (co-Chair), Georgia Institute of Technology, USA
Erwin Unruh, Fujitsu Siemens Computers, Germany
David Vandevoorde, Edison Design Group, USA
Todd Veldhuizen, Indiana University, USA

---------------------------------------------------------------------------

I'm giving talks at SD in San Jose in April

I've just been scheduled to give four presentations at the Software
Development Conference (http://www.sdexpo.com/) in San Jose on April 11 and
12. They're summarized at http://www.aristeia.com/seminars_frames.html,
but I'll save you the trouble of clicking:

ON WEDNESDAY, APRIL 11

Implementing a User-Defined operator->*

Most C++ programmers know little about operator->*, but the topic is both
interesting and instructive. Especially interesting is the use of
templates, including member and partially specialized templates. This
talk begins with a review of how operator->* is generally used, then
proceeds to examine two different ways to implement it for smart pointer
classes. It ends with a tantalizing idea: smart pointers to
members. (This talk is based on material in my 1999 DDJ article on the
same topic. You can read that article at
http://www.ddj.com/articles/1999/9910/9910b/9910b.htm.)

------------------------

The Strange Tale of auto_ptr

auto_ptr is a smart pointer template in the standard library with the
simplest of conceptual specificatons: an auto_ptr is an object that acts
just like a pointer, except it deletes what it points to when it (the
auto_ptr) is destroyed. This simple description turns out to mask a
design challege of considerable proportions, one that required two
fundamental rewrites during standardization, and even the final
specification for auto_ptr has noteworthy flaws. (For example, some of
its intended uses won't compile.)

This talk describes the tortured path auto_ptr travelled from initial
concept to final specification, focusing on the design challenges that
made auto_ptr so difficult to pin down. Attendees can expect to learn not
just about auto_ptr, but also about how several features of C++ can
interact to make a seemingly simple class extremely difficult to design.


ON THURSDAY, APRIL 12

Real World C++

When Scott started consulting on C++ projects, he figured his biggest
challenges would center on the proper use of language features. He was so
naive. Over the years, he's discovered that the biggest obstacles to
success in C++ involve a little C++, a fair amount of
language-independent software engineering, and a healthy dose of decent
management. This talk presents over a dozen specific guidelines that
Scott has found to significantly improve the chances of success on real
software projects in C++. Some guidelines focus on specific language
issues (e.g., casts, virtual destructors), while others focus on broader
matters (e.g., the need to embrace abstraction, the importance of
specifications, the need to develop staged releases). Compared to Meyers'
usual talks, this seminar is less intensively technical, but it covers a
broader array of issues, and it is definitely about C++ software
development.

------------------------

Something Cool in C++

Over the years, Scott has amassed a gallery of novel ways to use C++. In
this talk, he'll discuss one or more of these techniques. Perhaps he'll
discuss functors, maybe it'll be template-based dimensional analysis,
possibly it will involve traits or variations on the Visitor pattern, but
whatever the topic or topics, it's certain to demonstrate how C++
language features can be combined in unusual ways to produce elegant
solutions to real problems. Fasten your seat belts, it's going to be a
wild ride!

For the last talk, I'm currently leaning towards covering some of the
amazing stuff in Andrei Alexandrescu's soon-to-be-out "Modern C++ Design"
(http://www.aw.com/product/0,2627,0201704315,00.html), but I might decide
to go with something from my forthcoming "Effective STL" instead. (That
book will be out in mid-June, BTW. When more details become available,
this mailing list will be the first to know.) Or I might get inspired to
cover something completely different. That's the best thing about the
"Something Cool" talk: I get to cover whatever I want to :-)

I hope to see you at Software Development in April.

Scott

Updated Errata Lists, etc.

Three Topics this time:
- I've updated my publications' errata lists
- Template Workshop Status Report
- Reminder about my January STL Seminar

UPDATED ERRATA LISTS
--------------------
I just added the most recent batch of bug reports for EC++, MEC++, and the
EC++CD to their respective errata pages:
EC++ http://www.aristeia.com/BookErrata/ec++2e-errata_frames.html
MEC++ http://www.aristeia.com/BookErrata/mec++-errata_frames.html
EC++CD http://www.aristeia.com/BookErrata/cd1e-errata_frames.html

TEMPLATE PROGRAMMING WORKSHOP
-----------------------------
By all reports, the C++ template programming workshop in Erfurt, Germany in
October was a great success. All the papers that were presented there are
now available at http://www.oonumerics.org/tmpw00/, and I encourage you to
look them over. It looks like there will be a follow-up workshop next year
(possibly in conjunction with OOPSLA, but that's not yet decided), so start
thinking about whether you'd like to make submission for next year's
workshop. When details on next year's workshop are available, I'll include
them in a mailing to this list.

JANUARY STL SEMINAR
-------------------
My next STL seminar will take place January 22-25 near Portland, Oregon.
Based on my experience with the last public seminar as well as with some
on-site presentations, I've expanded the length of the course from three to
four days. You'll find all the details at
http://www.aristeia.com/seminars/eistl/index_frames.html. I hope to see
you there!

Scott

Upcoming Seminars; Template Workshop; Revamped Web Site

Three topics:
- Upcoming public seminars in November and January
- Template programming workshop in Germany in October
- My new "improved" web site

UPCOMING PUBLIC SEMINARS
------------------------

My revamped web site (see below) now features a page dedicated to my
upcoming public seminars, including the ones I'll be giving in Switzerland
and Germany in November and the one I'll be giving in Portland in January.
For details, visit http://www.aristeia.com/seminars/, then mark off some
time on your calendar to come listen to me prattle on about C++ :-)


TEMPLATE PROGRAMMING WORKSHOP
-----------------------------

The workshop on template programming I've mentioned in previous mailings
now has a final program, and you can find it at
http://www.oonumerics.org/tmpw00/. Having read all the submissions (we
could accept only 10 of 21), I can assure you that the presentations will
be very strong, and I just wish I could go myself. (I can't, sigh.) The
workshop will take place on Tuesday, October 10. (This is a day later than
originally scheduled, by the way). To register, visit
http://www.netobjectdays.org/node00/en/Register/index.html and sign up for
the conference; there is no special registration for the workshop alone.

If you can't attend, I encourage you to read the papers that will be
presented there. You'll be able to get to them via that same URL,
http://www.oonumerics.org/tmpw00/, but the links may not be present until
after the workshop.

One member of the Program Committe, reflecting on the submissions we
reviewed, shared this with the other members of the PC. He didn't expect
me to share it with others, but I think it accurately reflects the
workshop, and I thought you might find it interesting:

I was very pleasantly surprised by the quality of many of the papers
submitted to the workshop. Considering that this is a newly-born workshop
and it is held in Germany, the result is impressive. There are many
workshops held every year, some in conjunction with top quality
conferences. Most of them will just accept any paper that happens to be
submitted, expecting no novelty but instead repeating well-known
"positions" of the authors. Instead, the C++ template workshop has a
program that indeed allows it to claim that it is the premier outlet for
top-quality work in C++.

If you can make it to Erfurt next month, I think you'll find the workshop
well worth attending.


MY NEW "IMPROVED" WEB SITE
--------------------------

My web site has been revamped to include more information and to be easier
to navigate. If you find something wrong with the "new" www.aristeia.com,
please let me know. Please also let me know if you find my ISP flaky (they
host the site). I've received a report that the site is *very* slow and
that 10061 errors ("connection refused") are common. It works fine for me,
but then again, there are zero hops between me and my ISP. On the other
hand, I've heard this complaint from only one person, so I'm kind of hoping
it's just him...

BTW, please don't give me grief about my use of frames at the site. It was
the least unpleasant of the options I had at my disposal, and besides, I'm
still not using cookies. Nor do I plan to.

I want to plug the person who did the work on the web site, because I found
him to be extremely professional in every way. He was determined to
produce a site that I was happy with, even if that meant rewriting things
several times to get the effect I wanted (across multiple browsers), and he
was willing to do research to find out how my latest impossible demands
could be met. He was amazingly responsive, and I do mean that I was
amazed. I also found his fees to be quite reasonable. If you are looking
for somebody to help you with web site work, I encourage you to contact:

Mogenns Gilmour
WebCoach Internet Services Corp.
Providing Quality Internet Services Since 1995
Info@... | http://www.webcoach.com
Toll Free: 877-WebCoach (932-2622)
503-655-6813 (Voice) | 503-655-6907 (Fax)

Tell him I sent ya.

Scott

November Seminars

For a variety of reasons, the next time I offer a public seminar on my
introductory STL materials has been pushed back from this coming November
to the second half of January, 2001. (When firm dates are available, I'll
let you know.) If you were hoping to attend the November STL seminar, I
apologize for the delay, but there are a few things we need to take care of
before we offer the seminar again. When we do it, I want to make sure we
do it correctly.

If you're in Europe, however, you may want to note the following seminar
dates:

Basel, Switzerland: November 13-14
Munich, Germany: November 16-17

For both seminars, the first day will cover "Designing and Implementing
Effective C++ Classes" (http://www.aristeia.com/class-design.html), and the
second day will cover "High-Performance C++ Programming
(http://www.aristeia.com/high-performance.html). I'm overhauling the
material in the high-performance course to include information on the use
of the STL portion of the standard C++ library. That material appears in
neither "Effective C++" nor "More Effective C++", though it will appear in
"Effective STL," which I'm working on now and which I hope to have out by
the end of the year.

The seminars in Europe are being organized by Altmann & Partner AG and by
QA Systems GmbH. At some point they will have official publicity
materials, and when those material become available, I'll let you know.

Scott

Reminder: Submissions Deadline is August 11

This is just a quick reminder that the deadline for submissions for the
October Workshop on C++ Template Programming is August 11. If you're doing
interesting things with templates and you'd like to share your insights and
experiences with others, I encourage you to prepare a submission.

For details, please visit http://www.netobjectdays.org/tmpw/cfp.html and
scroll to the bottom half of the page.

Thanks,

Scott

PS - In theory, this mailing will be free of ads. If not, I'll see that
heads roll at egroups...

MEC++ Updates; Next STL Seminar; etc.

There are several topics this time:
- The MEC++ Errata Page has been updated.
- The M29 Source Code has been updated.
- My next STL seminar will likely be October 31 through November 3.
- I'm looking for a web site design/maintenance firm near Portland, OR.
- I'm still working on getting rid of the ads on these postings.


UPDATED MEC++ ERRATA LIST AND UPDATED M29 SOURCE CODE
-----------------------------------------------------

Having just tinkered with the More Effective C++ source for the next
printing (its tenth), I've updated its errata page. As usual, you can find
the errata at http://www.aristeia.com/BookErrata/mec++-errata.html.

One of the bug reports involved Item 29, so I updated the on-line version
of the code for that Item. To get the updated code, go to
http://www.aristeia.com/BookErrata/M29Source.html. The older source code
is available via a link at the AW MEC++ web site, but I'll ask AW to
replace that link with one to the URL I just gave you. This will prevent
me from having to ask AW to update their web site when I change the code
for M29 in the future. (This is also why I keep my books' errata pages at
my own site: it allows me to change them without bugging AW.)

BTW, the above link to the M29 source code is a Mailing List *exclusive*.
Aren't you excited?


MY NEXT STL SEMINAR
-------------------

Here's another exclusive:

My "Effective STL" seminar June 7-9 was a big success, so we'll be doing
another one, almost certainly October 31-November 3 at the same place (the
Crowne Plaza in Lake Oswego, a suburb of Portland, Oregon). The next one
will probably be four days instead of three, because nearly everybody who
attended the first one said they wished we'd had more time.

The seminar will probably be called "Essential STL" to reflect the
introductory nature of the material. That will allow me to use the name
"Effective STL" for a future non-introductory course that's based on
guidelines, just like "Effective C++" is.

When all the details have been worked out, we'll put up a web page for the
new seminar, and I'll post here to let you know it's up. For now, if
you're interested in attending a hands-on STL programming seminar led by
moi, reserve October 31 through November 3 and start bugging your boss for
time off and funding to attend :-)


KNOW ANY GOOD WEB SITE DESIGNERS NEAR PORTLAND, OREGON?
-------------------------------------------------------

Speaking of web sites, I'm looking for a reliable, professional web site
design and maintenance company located in or near Portland, Oregon. I'm
looking for somebody to design and maintain my own site (aristeia.com) as
well as to set up a site for my STL seminar, ideally including the ability
to accept registrations (including payment) automatically. I don't need
anything terribly fancy, but I do require somebody who is reliable, gets
work done in a timely fashion, and who is as picky about things as I am.
If you perform this kind of service or you know somebody who does, please
let me know (smeyers@...).

(To get some idea of how I feel about web site design, you might take a
look at the Introduction to my "Effective C++ CD", which you can read at
http://www.awlonline.com/cseng/meyerscddemo/DEMO/INTRO/INDEX.HTM. I'm not
looking for a site offering all the features of my CD, but I am looking for
somebody whose thoughts about web site design are similar to my own.)


ADS ON MY MAILING LIST POSTINGS
-------------------------------

I ran into a snafu in getting rid of the ads that accompany my mailing list
postings, and I apologize for that. I'm working on it, and I hope to have
it all taken care of by the end of the month. (Executive summary: I sent
egroups a check, but they never got it.)


Scott


IMPORTANT: I've been having trouble with my email recently, so if you
reply to this, PLEASE check to make sure you're sending to
"smeyers@...". If the reply address comes up as
"root@...", PLEASE let me know so I can try to debug the problem!

Workshop on Template Programming

Somehow I ended up as the Program Chair for a workshop on template
programming in C++ in Germany this coming October. The Call for Extended
Abstracts is below. If you've been doing interesting work with templates,
I encourage you to consider submitting a paper.

Scott




CALL FOR EXTENDED ABSTRACTS

WORKSHOP ON C++ TEMPLATE PROGRAMMING
(http://www.netobjectdays.org/tmpw/)

October 9, 2000
Erfurt, Germany

in Conjunction with the
Second International Symposium on
Generative and Component-Based Software Engineering (GCSE 2000)
(http://www.netobjectdays.org/gcse/)


One of the most exciting research areas in C++ focuses on the use of
templates, especially as a means to support generic and generative
programming. A number of powerful, flexible, and useful techniques have
been developed, but to date there has been no forum where workers in the
field of C++ template programming could gather to hear about one another's
work. The purpose of this workshop is to provide an opportunity for people
interested in C++ template programming to gather and exchange ideas.

We encourage submission of extended abstracts of up to 10 pages on any
aspect of C++ template programming, including (but not limited to) the
following:

Generic and generative programming in C++
Uses or extensions of the STL or other templates in the standard libray
Traits and traits-based programming
Iterators for multidimensional data structures
Template metaprogramming, including the representation of
metainformation in C++
Combining static configuration with dynamic techniques
Expression templates
Experience reports on template programming
Debugging template code
Compiler support for templates, including compilation times and diagnostics
Implementing C++'s template features
Portability issues
Template design and programming techniques

We are as interested in the application of templates as in their design and
implementation. Papers describing novel and interesting uses of the STL or
other existing template libraries are as welcome as papers describing the
design and implementation of new templates.

Our primary interest is in abstracts describing new work, but we will
consider abstracts based on prior publications. (Work that has already
been published should be identified as such.) One of our goals is to
increase the visibility of information likely to be helpful to other
workers in the field of C++ template programming.

A workshop proceedings will be produced in electronic form, to be made
available via the Internet or on CD by the time of the workshop.


SUBMISSION GUIDELINES:

Extended abstracts of no more than 10 pages should be sent to
workshop@.... Electronic submission in HTML or PDF is strongly
preferred. Questions about the submission process should be sent to
workshop@....


IMPORTANT DATES:
11 August Extended Abstract Submissions Due
4 September Notification of Accepted Submissions
29 September Final Extended Abstracts Due


PROGRAM COMMITTEE:
Andrei Alexandrescu, RealNetworks, Inc., USA
Matt Austern, AT&T Research, USA
Thomas Becker, Zephyr Associates, Inc., USA
Ulrich Breymann, Hochschule Bremen, Neustadtswall, Germany
Krzysztof Czarnecki, DaimlerChrysler AG, Germany
Ulrich Eisenecker, University of Applied Sciences, Kaiserslautern, Germany
Nicolai Josuttis, Author and Consultant, Germany
Scott Meyers (Chair), Author and Consultant, USA
Mark Rodgers, Cadenza New Zealand Ltd, New Zealand
Yannis Smaragdakis, Georgia Institute of Technology, USA
Erwin Unruh, Fujitsu Siemens Computers, Germany

Migration to egroups should now be complete

In theory, everybody on my mailing list has now been transferred from the
soon-to-be-defunct list at my ISP to my list at egroups. I'm sending this
message to both lists, so if you get two copies of this message, it means
you were on the ISP-hosted list and you have been successfully moved to the
egroups-hosted list. If you get only one copy of this message and if that
one copy did NOT come from egroups, it means you somehow failed to get
moved from my ISP to egroups. In that case only, please go to
http://www.egroups.com/list/scott_meyers/info.html and sign up for my
mailing list at egroups.

This is the last message I will send to my ISP-hosted list. I apologize
for bogging everybody down in what should ideally be a completely
transparent migration of list-hosting sites.

Scott

PS - I apologize if this or other egroups-based messages come through with
ads attached. I've sent egroups a check and have told them to
eliminate the ads, but it may take a little while for them to tend to
it. Please be patient.

Effective STL Seminar SOLD OUT

I just received word that my June "Effective STL" seminar has reached its
enrollment limit of 35. If you'd like to be placed on the wait list (in
case somebody cancels), let Nancy Pastrano know at nancy_pastrano@....

If you'd been thinking of attending but didn't sign up, take heart: we'll
probably do the seminar again in early November. As always, when more
information is available, this mailing list will be the first to know.

Scott

Errata Update; Seminar Update; Mailing List Update

Three things:
- EC++ errata updated.
- Enrollment limit placed on June STL Seminar.
- Mailing list migration in the offing.

----------------------------------------------------------------------

I just uploaded an updated version of the Effective C++ errata list. This
is because I modified the source in preparation for the ninth printing. Of
all the changes, this is the most significant:

  ! 1/21/99 sdm 225-6 Contrary to the second bullet on this page,         4/28/00
                      names introduced via standard C headers *are* in
                      namespace std. Matt Austern explained the
                      reason for this in a posting to
                      comp.lang.c++.moderated on 1/18/00:

                        <cfoo> headers define symbols in namespace std
                        only, while the <foo.h> headers define them in
                        namespace std and then import them into the
                        global namespace as if by using-declarations.
                        This is described in section D.5, paragraph 2,
                        of the C++ standard.

                        It clearly wouldn't work for the <cfoo>
                        headers to define names in namespace std only
                        and for the <foo.h> headers to define names in
                        the global namespace only. If we did it that
                        way then (for example) we'd get two different
                        ldiv_t types, one from <stdlib.h> and one from
                        <cstdlib>. As is we've instead got a single
                        ldiv_t that can be referred to from two
                        different namespaces. Because of Koenig
                        lookup, it makes a difference which one it was
                        originally defined in.

                      I reworded the bullets to state for each one
                      what's in the global namespace, what's in std,
                      and what's in both.

* * *

For a variety of reasons, we just placed an enrollment limit of 35 on the
STL seminar I'll be presenting in June (http://www.trekservices.com/estl/).
Because the class won't be too big, I'm hoping to have a lot of interaction
with everybody who attends. Last I heard, there were about 30 people
signed up, so if you're interested in attending the seminar, now would be a
good time to grab one of the remaining slots. It also looks like I'm
managing to convince several people with lots of STL experience to drop in
and offer help during exercises, so this should be a good opportunity to
have people look over your shoulder and explain that the error message that
never uses the word "iterator" is complaining about your iterators :-)

* * *

Because my ISP is discontinuing support for mailing lists, I've set up a
new mailing list at eGroups,
http://www.egroups.com/list/scott_meyers/info.html. I'm not yet done
setting things up, but when I'm finished with that, I'll do my best to
transfer everybody over from the current mailing list to the new one. In
theory, nothing can possibly go wrong (ahem), but don't be surprised if you
get a few pieces of mail in the next couple of weeks that serve only to
tell you about mailing list administrivia. With any luck, this will be a
painless transition for all of us.

Scott

Updated CD Errata, More STL Seminar Info, Pending Mailing List Change

In preparation for the next printing of the Effective C++ CD, I've updated
the CD's Errata Page (http://www.aristeia.com/BookErrata/cd1e-errata.html)
to include my latest changes.

Also, I'm increasingly excited about the Effective STL Seminar I'll be
hosting June 7-9, because last week I got a chance to teach the
brand-spanking-new material for the first time. The course was
enthusiastically received, but of course I'll be tinkering with things here
and there so that future presentations are even better. For example, I'm
working on a special handout on card stock that will summarize all 70+ STL
algorithms. I'll be teaching the course again at a corporate site at least
one more time before June, so by the time the "real" seminar rolls around,
I expect to have things pretty well refined. For details on the June
seminar, please visit http://www.trekservices.com/estl/.

Also on the topic of the June seminar, some people have requested a fourth
day of STLification, to take place Saturday, June 10. I'm willing to work
on a Saturday if you are, so if you're interested in an additional day (at
an additional cost -- we're still working on the details), be sure to let
Nancy Pastrano know when you register.

Finally, my ISP has decided to discontinue its support for mailing lists,
so sometime in the next few weeks, I'll be moving my mailing list to
someplace else. Already, I see, my archive of old messages seems to be
gone. Sigh. When I know more, I'll let you know, and I apologize for the
inconvenience.

Scott

Effective STL Seminar

It took a little longer than expected, but we have finally worked out the
details for the Effective STL seminar I'll be offering in Portland, Oregon,
on June 7-9. Here's the executive summary:

Effective STL: A Hands-On Programming Seminar with Scott Meyers
Lake Oswego, Oregon (a suburb of Portland)
June 7-9 (Wednesday-Friday)
$1350

A lot more information is available at the seminar's web site:

http://www.trekservices.com/estl/

To register for the seminar or to ask questions about it, please contact
Nancy Pastrano of Trek Services: NPastrano@TREKServices.com. She's
handling all the administrative and logistical work. You can also contact
her with questions about the technical aspects of the seminar. If she
can't answer them, she'll forward them to me.

I hope to see you at the seminar in June!

Scott

October DDJ Article Now On-Line

DDJ has now put my October article on operator->* on the web. The URL is
http://www.ddj.com/articles/1999/9910/9910b/9910b.htm

I'd hoped they'd put a version of the article up that doesn't separate the
code examples into listings following the article proper, but they chose
not to do that. Fortunately, there are links between the article text and
the listings, so it's pretty easy to switch back and forth.

The contract I signed with DDJ did not oblige them to make the article
freely accessible, so I hope you'll send the editor, Jon Erickson, mail
thanking him for his willingness to do it. His address is
jerickson@ddj.com.

Scott

CUJ Article is now out; June Seminar Reminder

My artice, "How Non-Member Functions Imrove Encapsulation", is now
available in the current issue of the C/C++ Users Journal. I think this is
some of the best work I've done in a while, and I hope you find it
interesting. Here is the opening paragraph:

I'll start with the punchline: If you're writing a function that can be
implemented as either a member or as a non-friend non-member, you should
prefer to implement it as a non-member function. That decision
*increases* class encapsulation. When you think encapsulation, you
should think non-member functions.

To my great delight, the entire article is also available on-line at
http://www.cuj.com/current/feature.html. CUJ and I had agreed in advance
that the article would eventually be made available via the web, but I
didn't expect them to make it available electronically at the same time as
the print version. I encourage you to send the editor, Marc Briand, mail
thanking him for making the article so easily accessible. His address is
mbriand@mfi.com.

We're still working on the details, but my hands-on "Effective STL" seminar
is planned for June 7-9 near Portland, Oregon. Within the next couple of
weeks, I'll send out a mailing with all the information you'll need, but
for the time being, I hope you'll plan to join me June 7-9 to get down and
dirty with the STL -- the most revolutionary library design I've ever seen,
and one we're darned lucky to have as part of standard C++.

Scott

PS - In an earlier mailing, I told you that my DDJ article on operator->*
would soon be available on-line. I'm still waiting to hear from DDJ about
when "soon" will be. When I know, I'll let you know.

October MIND Article is now On-Line

Well isn't it just like Microsoft to make a liar out of me? I got word
today that my October MIND article is now fully available on-line. You can
get to it at http://www.microsoft.com/Mind/1099/browsing/browsing.htm.

Scott

Updated errata lists; Article stuff; Effective STL Seminar

Three topics:

1. UPDATED ERRATA LISTS for Effective C++, More Effective C++, and
the Effective C++ CD

2. ARTICLE STUFF, including imminent on-line availablity of my October
DDJ article and advance notice of my upcoming CUJ article.

3. ADVANCE NOTICE OF MY EFFECTIVE STL SEMINAR, to be held in Portland,
Oregon, in June, 2000.


UPDATED ERRATA LISTS:
---------------------

On the off chance the world fails to end at midnight on December 31, I
updated my publications' errata lists for the new millennium.

- The errata list for Effective C++ is still at
http://www.aristeia.com/BookErrata/ec++2e-errata.html. New entries are
dated 5/24/99 or later.

- The errata list for More Effective C++ remains at
http://www.aristeia.com/BookErrata/mec++-errata.html. New entries are
dated 10/8/99 or later.

- The errata list for the Effective C++ CD continues to dwell at
http://www.aristeia.com/BookErrata/cd1e-errata.html. New entries are
dated 7/6/99 or later.

I asked AW to update the auto_ptr page that they maintain, but I have no
idea how long it will take them to do it. Fortunately, the change is quite
small. This is what I sent them:

At the MEC++ auto_ptr update page
(http://www.awl.com/cseng/titles/0-201-63371-X/auto_ptr.html), one
paragraph reads as follows:

As it turns out, the dust hasn't quite settled on auto_ptr, because some
minor errors have been detected in the standard's specification: it
doesn't quite say what the standardization committee wanted it to
say. When everything is taken care of, I'll update this page again to let
you know the details.

I'd appreciate it if you'd add the following sentence to the end of the
above paragraph:

(If you just can't wait that long, search for "auto_ptr" in the href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html">Active
Issues List for the C++ Standard Library.)

Finally, I added email from Bill Wade to the M27 page (it's devoted to
determining whether an object is on the heap). That page remains at
http://www.aristeia.com/BookErrata/M27Comments.html.


ARTICLE STUFF:
--------------

DDJ has generously agreed to make my October article on operator->*
available on-line sometime in the near future. I'll let you know the URL
when they tell me what it is. This is very nice of the DDJ people, because
they don't generally make their articles available for free, so I hope
you'll send them fan mail. In the future, I expect all my magazine
articles to be available on-line a couple of months after they appear in
print, because I'm making that a standard condition when I submit things
for publication.

I've asked the MIND people to make my October article from there available
on-line, too, but I haven't heard back from them, and MS is not known for
its cooperative nature on these matters. Don't get your hopes up.

I'll have a new article in the February CUJ (unless it gets bumped to a
different issue between now and then). I'll use this mailing list to let
you know when the article is out, but let me say right now that I think the
article is one of the most important things I've written in a long time.
This is how it opens:

I'll start with the punchline: If you're writing a function that can be
implemented as either a member or as a non-friend non-member, you should
prefer to implement it as a non-member function. That decision
*increases* class encapsulation. When you think encapsulation, you
should think non-member functions.

I expect this to drop some jaws, but of course, that's the point :-)


EFFECTIVE STL SEMINAR:
----------------------

Recently, I've been looking into the STL in preparation for what I hope
will become a book on the topic written at the level of Effective C++. The
working title is -- duh -- "Effective STL". Yes, you heard it here first.
No, I don't know when the book will be done :-)

Regardless of whether the book comes to fruition, I'm planning to conduct a
hands-on seminar on effective use of the STL in Portland, Oregon, in June
of 2000, probably during the week of June 5-9. The basic idea will be a
combination of lectures and hands-on labs led by me, with the focus being
how to *use* the STL instead of dwelling on the tedium behind things like
iterator categories and what it means to be a model of EqualityComparable.
As in my other C++ books, the material will be broken down into bite-sized
guidelines, and I'm hopeful that this format will be as useful to C++
programmers using the STL as it has been for the non-STL parts of the
language.

I'll have details about the seminar (length, dates, cost, prerequisites,
etc.) in a mailing in the first half of January, but for the time being,
please try to set aside the time and budget to join me in June to learn how
to make *effective* use of the most revolutionary library I have ever seen.
As I mentioned, the seminar is tentatively scheduled to take place the week
of June 5-9, but if you have strong feelings about which week in June it
should occur, send your thoughts to Nancy Pastrano
(NPastrano@TrekServices.com); she'll be handling the logistics for the
event. Nancy's help leaves me time to mull over the significance of the
fact that the non-member algorithm "find" and the member algorithm "find"
don't generally behave the same way, so replacing one with the other does
more than just affect performance...

Scott

Updated MEC++ Errata; Talks at C++ World

Two topics:
- The MEC++ errata list has just been updated
- I'll be speaking at C++ World in Miami in December

I've just updated the errata page for More Effective C++. You'll find it
at http://www.aristeia.com/BookErrata/mec++-errata.html. I'd hoped to
include the latest changes in this mailing as a Mailing List Exclusive, but
I wasn't really set up for that. In the future, I'll try to organize my
bookkeeping so that when I update an errata list, I can include the changed
entries in the message that announces the updated list.

I've agreed to speak at the "C++ World" conference in Miami on December 2
and 3. For details, check out http://www.cwconference.com/. The talks I'm
going to give are described below. These are the descriptions I submitted
to the conference organizers, but the descriptions you'll see in brochures,
etc., will be shorter, because it's important that all conferences hack the
talk abstracts until they bear little resemblance to what the speaker
originally submitted. Ahem.

Real World C++ (Renamed "Succeeding with C++" at the behest of the
conference organizers. Don't ask.)

When Scott started consulting on C++ projects, he figured his biggest
challenges would center on the proper use of language features. He was
so naive. Over the years, he's discovered that the biggest obstacles to
success in C++ involve a little C++, a fair amount of
language-independent software engineering, and a healty dose of decent
management. This talk presents over a dozen specific guidelines that
Scott has found to significantly improve the chances of success on real
software projects in C++. Some guidelines focus on specific language
issues (e.g., casts, virtual destructors), while others focus on broader
matters (e.g., the need to embrace abstraction, the importance of
specifications, the need to develop staged releases). Compared to Meyers'
usual talks, this seminar is less intensively technical, but it covers a
broader array of issues, and it is definitely about C++ software
development.


Implementing operator->*

Most C++ programmers know little about operator->*, but the topic is both
interesting and instructive. Especially interesting is the use of
templates, including member and partially specialized templates. This
talk begins with a review of how operator->* is generally used, then
proceeds to examine two different ways to implement it for smart pointer
classes. It ends with a tantalizing idea: smart pointers to members.


The Strange Tale of auto_ptr

auto_ptr is a smart pointer template in the standard library with the
simplest of conceptual specificatons: an auto_ptr is an object that acts
just like a pointer, except it deletes what it points to when it (the
auto_ptr) is destroyed. This simple description turns out to mask a
design challege of considerable proportions, one that required two
fundamental rewrites during standardization, and even the final
specification for auto_ptr has noteworthy flaws. (For example, some of
its intended uses won't compile.)

This talk describes the tortured path auto_ptr travelled from initial
concept to final specification, focusing on the design challenges that
made auto_ptr so difficult to pin down. Attendees can expect to learn
not just about auto_ptr, but also about how several features of C++ can
interact to make a seemingly simple class extremely difficult to design.


The material in the talk on operator->* is the same as that published in
the current issue of Dr. Dobbs Journal.

Scott