Two topics this time:
- An all-new "THE C++ Seminar" will take place in Boston in March.
- I'll be giving four talks at Software Development in San Jose in April.
TCS2 (THE C++ Seminar 2)
------------------------
The initial "THE C++ Seminar" was so successful and so much fun, we decided
to do it again, this time in Boston in March. (If you're not familiar with
"THE C++ Seminar", you can read about the idea behind it at
http://groups.yahoo.com/group/scott_meyers/message/17 and can get detailed
information about it at http://www.gotw.ca/cpp_seminar/)
There is an important difference between the seminar we held in October and
the one we'll host in March: virtually all of the material will be new.
Really new. So new, it's never been presented before any any public forum
and has never appeared in a book or magazine article. (At least not one we
wrote.) That means that if you attended TCS1 or have read every word we've
ever published, you can sign up for TCS2 without fear of seeing the same
tired stuff you've seen before. (We may decide to repeat a couple of the
panel sessions we did at TCS1, but all of the individual talks will be new,
and I'm pushing to avoid panel repeats, too.)
You'll find general TCS information at http://www.gotw.ca/cpp_seminar/.
Registration information for TCS2 is at
http://www.gotw.ca/cpp_seminar/02/index.htm. A discounted "early bird"
registration fee applies until the end of January. I encourage you to
register early, because TCS1 was nearly sold out by the end of its early
bird period.
Software Development
--------------------
I'll be speaking at the Software Development Conference
(http://www.sdexpo.com/) again this year. I'm giving three C++ talks:
STL Allocators
Maximizing STL Performance
C++ Odds and Ends
I'm also giving a keynote address that is about software development in
general (as opposed to specifically about C++):
The Keyhole Problem and its Many Kin
You can find descriptions of all of these talks at
http://cmp.bluedot.com/re/attendee/wsw_02/speakerPage.esp?speakerId=36633866
Regarding the conference, the SD bigwigs have asked me to let you know the
following:
We have a special offer for any attendees whom you refer to SD West
2002. If they use the code 2WSPKR, they will receive $300 off any
multi-day pass with no expiration date!
An offer like that kind of takes your breath away, doesn't it?
I hope everybody is having a happy holiday season, and I hope to see you in
Boston in March, in San Jose in April, or both.
Scott
Wednesday, December 19, 2001
Tuesday, October 30, 2001
ESTL Errata List has been Updated
In preparation for the upcoming third printing of Effective STL, I've
fully updated the ESTL Errata list, including the addition of a number of
new bug reports and "interesting comments." My raw notes for the latest
delta are below, but things got massaged a fair amount as I integrated the
new material into the old list, so don't be surprised when you find
differences between what's below and what's in the list at
http://www.aristeia.com/BookErrata/estl1e-errata_frames.html.
My favorite bug in the book so far, though not one of the new ones below,
is the one reported for page 126, where I and every one of my pre-pub
reviewers overlooked the fact that in several places on the page, I'd
written "operator<<" where I clearly meant "operator>>". When reading the
manuscript, each of us saw what we wanted to see -- what we *expected* to
see -- instead of what was actually on the page. I marveled when that was
reported. But not right away. First I had to read the report over several
times. It look that long for my eyes to see that what was in ink was not
what was in my brain.
Scott
[Raw notes for latest ESTL errata update]
DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
9/ 4/01 bww iv Change "Meyer, Scott" to "Meyers, Scott" in the
Library of Congress Cataloging-in-Publication
Data.
10/ 4/01 ap 47 In 1st para, clarify that erase's return value
is void in associative containers only for the
forms taking iterators. (When passed a value,
erase returns the number of elements erased.)
10/24/01 wg 66 The first sentence of the third paragraph begins,
"Given all that ..., It should not". The word
"it" is errantly capitalized.
10/11/01 gn 67 In second and third bullets, the parameters
taken by resize and reserve are of type
Container::size_type, not size_t (though for all
the standard containers, Container::size_type
must be size_t).
10/11/01 gn 67 In second bullet, it is worth noting that there
is also a two-argument version of resize, the
second argument specifying the value to copy
into new elements if the container needs to be
increased in size.
8/22/01 jep 68 At end of 2nd-to-last para of Item 14, note that
any use of push_back would invalidate an
end iterator, e.g., one initialized from s.end().
! 10/11/01 gn 99 In the long middle para, casting away the
constness of a map key doesn't yield undefined
behavior, but attempting to MODIFY the key
does.
8/22/01 jep 100 Step 5 says that giving an accurate hint to the
"hint" form of insert yields constant-time
complexity, but it actually yields amortized
constant time complexity. Fixing this requires
that I also modify page 6 to define "amortized
constant time," and I'll have to add the term to
the index, too.
8/22/01 jep 104 In the 4th comment from the top of the page, the
reference to Item 45 should really be to Item 19.
8/22/01 jep 110 As in jep's bug report for page 100 above,
insertion with a hint yields amortized constant
time complexity, not simply constant time.
10/11/01 gn 118 In first line of second bullet, "const iterator"
==> "const_iterator". The latter should be
in code font.
8/22/01 jep 118-9 The Standardization Committee appears to be on
the verge of officially deciding that
comparisons between iterators and
const_iterators should always compile. For
details, consult href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#179">Library
Working Group Issue
#179. While you're there, note the link to
href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#280">Issue
#280, where you'll see that whether to
require comparisons of reverse_iterators and
const_reverse_iterators is not yet resolved.
! 8/22/01 jep Item 27 The code shown in this Item is sanctioned by
the Standard for every standard container except
string, and it should also work for any string
implementation that avoids reference counting.
For strings using reference counting, calling
begin() may invalidate existing iterators, and
that leads to this problem:
typedef string::iterator Iter;
typedef string::const_iterator ConstIter;
string s;
ConstIter ci;
... // make ci point into s
Iter i(s.begin()); // calling begin
// invalidates ci!
advance(i, distance(i, ci));
// pass invalidated ci
// to distance
A use of advance and distance that should work
with any standard container c (including strings
employing reference counting) is this:
Container::difference_type d =
distance(c.begin(), ci);
Iter i(c.begin()); // invalidates ci, but we
// don't need it any more
advance(i, d);
9/21/01 fk 136 At the top of the page, begin and end should
probably be declared const. (In fact, I should
probably look at all the code examples in the
book to see if other local vars could be
declared const, too.)
! 8/22/01 jep 159 In the second call to accumulate on this page,
1.0 should be 1.0f. The comment should also be
adjusted, as should the sentence after the example.
9/ 8/01 dxc Item 23 This Item focuses on lookup time, but overall
performance is determined by both setup time
(including the time to sort the vector) and lookup
time. Clarify that the assumption underlying this
Item is that the number of lookups vastly dominates
the number of insertions and erasures.
Interesting Comments:
DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
10/11/01 gn 33 Regarding the declaration of the function int f(double(d))
at the bottom of the page, the text suggest that the
parentheses are ignored. Well, it depends on what d is. If
it is a type-name then the function is
int f(double (*)(d)), and that is not the same as
int f(double d). The d must be looked up in this case to
determine if it is a type-name or not. See 8.2/7.
typedef int d;
int f(double(d)); // d is a type-name =>
// int f(double (*)(int));
int d;
int f(double(d)); // d isn't a type-name =>
// int f(double);
10/11/01 gn 53 Though the book is correct that the type of the allocator
for ListNodes is
Allocator::rebind::other
you'd have to express that type like this in a program:
typename Allocator::template rebind::other
Pages 7-8 explain why the "typename" is necessary, and the
use of "template" here is similarly required to help the
parser process things correctly.
8/22/01 jep 66 The "aptly named max_size member function" does nothing
more than return a number based on the number of bits in
size_type. It has nothing to do with how many items may
really be placed in any of the containers without
exceeding memory.
8/22/01 jep 90-91 You don't have to create a functor class, because
you could use stringPtrLess's type, then pass
stringPtrLess as a constructor argument:
bool stringPtrLess (string const*, string const*);
typedef bool (*StringPtrLess) (string const*,
string const*);
set ssp(stringPtrLess);
This is legal code, but I consider it highly ill-advised,
because it allows for the possibility that you have
multiple containers of the same type but with
different
sort orders. To me, that's a recipe for disaster, and
that's why I went out of my way to avoid mentioning it in
the book.
8/22/01 jep Item 21 Using less_equal is even worse than you say. The average
quicksort used in sort will crash with some data sets.
Neither 10A nor 10B will be in the range of equal_range.
For { 9 10B 10A 11 } I got find(10) is end,
lower_bound(10) is 11, upper_bound(10) is 10B, and
equal_range(10) is [11, 10B), an invalid range.
9/21/01 fk Item 37 fk points out that the accumulate approach to computing
the average of a set of points involves multiple
divisions, while the for_each approach does only a single
division at the end. As a result, he suggests that the
for_each approach may be more accurate. This seems likely
to me. At any rate, it's all but certain that for some
sets of points, the accumulate and for_each approaches
will yield slightly different averages due to the
complexities of floating point math.
10/14/01 kg Item 37 There is a notable difference between the accumulate and
the for_each approaches to this problem. When the range
is empty, accumulate returns Point(0,0), but calling
result on the functor returned from for_each yields
undefined behavior due to division by zero.
fully updated the ESTL Errata list, including the addition of a number of
new bug reports and "interesting comments." My raw notes for the latest
delta are below, but things got massaged a fair amount as I integrated the
new material into the old list, so don't be surprised when you find
differences between what's below and what's in the list at
http://www.aristeia.com/BookErrata/estl1e-errata_frames.html.
My favorite bug in the book so far, though not one of the new ones below,
is the one reported for page 126, where I and every one of my pre-pub
reviewers overlooked the fact that in several places on the page, I'd
written "operator<<" where I clearly meant "operator>>". When reading the
manuscript, each of us saw what we wanted to see -- what we *expected* to
see -- instead of what was actually on the page. I marveled when that was
reported. But not right away. First I had to read the report over several
times. It look that long for my eyes to see that what was in ink was not
what was in my brain.
Scott
[Raw notes for latest ESTL errata update]
DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
9/ 4/01 bww iv Change "Meyer, Scott" to "Meyers, Scott" in the
Library of Congress Cataloging-in-Publication
Data.
10/ 4/01 ap 47 In 1st para, clarify that erase's return value
is void in associative containers only for the
forms taking iterators. (When passed a value,
erase returns the number of elements erased.)
10/24/01 wg 66 The first sentence of the third paragraph begins,
"Given all that ..., It should not". The word
"it" is errantly capitalized.
10/11/01 gn 67 In second and third bullets, the parameters
taken by resize and reserve are of type
Container::size_type, not size_t (though for all
the standard containers, Container::size_type
must be size_t).
10/11/01 gn 67 In second bullet, it is worth noting that there
is also a two-argument version of resize, the
second argument specifying the value to copy
into new elements if the container needs to be
increased in size.
8/22/01 jep 68 At end of 2nd-to-last para of Item 14, note that
any use of push_back would invalidate an
end iterator, e.g., one initialized from s.end().
! 10/11/01 gn 99 In the long middle para, casting away the
constness of a map key doesn't yield undefined
behavior, but attempting to MODIFY the key
does.
8/22/01 jep 100 Step 5 says that giving an accurate hint to the
"hint" form of insert yields constant-time
complexity, but it actually yields amortized
constant time complexity. Fixing this requires
that I also modify page 6 to define "amortized
constant time," and I'll have to add the term to
the index, too.
8/22/01 jep 104 In the 4th comment from the top of the page, the
reference to Item 45 should really be to Item 19.
8/22/01 jep 110 As in jep's bug report for page 100 above,
insertion with a hint yields amortized constant
time complexity, not simply constant time.
10/11/01 gn 118 In first line of second bullet, "const iterator"
==> "const_iterator". The latter should be
in code font.
8/22/01 jep 118-9 The Standardization Committee appears to be on
the verge of officially deciding that
comparisons between iterators and
const_iterators should always compile. For
details, consult href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#179">Library
Working Group Issue
#179. While you're there, note the link to
href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#280">Issue
#280, where you'll see that whether to
require comparisons of reverse_iterators and
const_reverse_iterators is not yet resolved.
! 8/22/01 jep Item 27 The code shown in this Item is sanctioned by
the Standard for every standard container except
string, and it should also work for any string
implementation that avoids reference counting.
For strings using reference counting, calling
begin() may invalidate existing iterators, and
that leads to this problem:
typedef string::iterator Iter;
typedef string::const_iterator ConstIter;
string s;
ConstIter ci;
... // make ci point into s
Iter i(s.begin()); // calling begin
// invalidates ci!
advance(i, distance
// pass invalidated ci
// to distance
A use of advance and distance that should work
with any standard container c (including strings
employing reference counting) is this:
Container::difference_type d =
distance
Iter i(c.begin()); // invalidates ci, but we
// don't need it any more
advance(i, d);
9/21/01 fk 136 At the top of the page, begin and end should
probably be declared const. (In fact, I should
probably look at all the code examples in the
book to see if other local vars could be
declared const, too.)
! 8/22/01 jep 159 In the second call to accumulate on this page,
1.0 should be 1.0f. The comment should also be
adjusted, as should the sentence after the example.
9/ 8/01 dxc Item 23 This Item focuses on lookup time, but overall
performance is determined by both setup time
(including the time to sort the vector) and lookup
time. Clarify that the assumption underlying this
Item is that the number of lookups vastly dominates
the number of insertions and erasures.
Interesting Comments:
DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
10/11/01 gn 33 Regarding the declaration of the function int f(double(d))
at the bottom of the page, the text suggest that the
parentheses are ignored. Well, it depends on what d is. If
it is a type-name then the function is
int f(double (*)(d)), and that is not the same as
int f(double d). The d must be looked up in this case to
determine if it is a type-name or not. See 8.2/7.
typedef int d;
int f(double(d)); // d is a type-name =>
// int f(double (*)(int));
int d;
int f(double(d)); // d isn't a type-name =>
// int f(double);
10/11/01 gn 53 Though the book is correct that the type of the allocator
for ListNodes is
Allocator::rebind
you'd have to express that type like this in a program:
typename Allocator::template rebind
Pages 7-8 explain why the "typename" is necessary, and the
use of "template" here is similarly required to help the
parser process things correctly.
8/22/01 jep 66 The "aptly named max_size member function" does nothing
more than return a number based on the number of bits in
size_type. It has nothing to do with how many items may
really be placed in any of the containers without
exceeding memory.
8/22/01 jep 90-91 You don't have to create a functor class, because
you could use stringPtrLess's type, then pass
stringPtrLess as a constructor argument:
bool stringPtrLess (string const*, string const*);
typedef bool (*StringPtrLess) (string const*,
string const*);
set
This is legal code, but I consider it highly ill-advised,
because it allows for the possibility that you have
multiple containers of the same type but with
different
sort orders. To me, that's a recipe for disaster, and
that's why I went out of my way to avoid mentioning it in
the book.
8/22/01 jep Item 21 Using less_equal is even worse than you say. The average
quicksort used in sort will crash with some data sets.
Neither 10A nor 10B will be in the range of equal_range.
For { 9 10B 10A 11 } I got find(10) is end,
lower_bound(10) is 11, upper_bound(10) is 10B, and
equal_range(10) is [11, 10B), an invalid range.
9/21/01 fk Item 37 fk points out that the accumulate approach to computing
the average of a set of points involves multiple
divisions, while the for_each approach does only a single
division at the end. As a result, he suggests that the
for_each approach may be more accurate. This seems likely
to me. At any rate, it's all but certain that for some
sets of points, the accumulate and for_each approaches
will yield slightly different averages due to the
complexities of floating point math.
10/14/01 kg Item 37 There is a notable difference between the accumulate and
the for_each approaches to this problem. When the range
is empty, accumulate returns Point(0,0), but calling
result on the functor returned from for_each yields
undefined behavior due to division by zero.
Tuesday, September 18, 2001
Registration for THE C++ Seminar Reopened
Last week's terrorist attack forced us to postpone THE C++ Seminar, which
was orignally scheduled for this week. The new dates are October 15-17,
and if there's anything that can be considered "good" about the
postponement, it's that we were able to reserve a room that can accommodate
more people this time. After existing registrants are given a chance to
roll over their registrations and people from the wait list are given a
chance to enroll, there are likely to be a dozen or so empty slots. If you
are interested in being able to participate in a hard-core C++ seminar with
me, Herb Sutter, Dan Saks, Steve Dewhurst, and Andrei Alexandrescu, I
encourage you to visit the seminar's home page
(http://www.gotw.ca/cpp_seminar/) to view the schedule and details on how
to register.
I hope to see you at the seminar, where I can promise a certain amount of
fireworks as I attempt to convince my head-in-the-sand compatriots that
namespaces, templates, and exceptions aren't necessarily all they're
cracked up to be...
Scott
was orignally scheduled for this week. The new dates are October 15-17,
and if there's anything that can be considered "good" about the
postponement, it's that we were able to reserve a room that can accommodate
more people this time. After existing registrants are given a chance to
roll over their registrations and people from the wait list are given a
chance to enroll, there are likely to be a dozen or so empty slots. If you
are interested in being able to participate in a hard-core C++ seminar with
me, Herb Sutter, Dan Saks, Steve Dewhurst, and Andrei Alexandrescu, I
encourage you to visit the seminar's home page
(http://www.gotw.ca/cpp_seminar/) to view the schedule and details on how
to register.
I hope to see you at the seminar, where I can promise a certain amount of
fireworks as I attempt to convince my head-in-the-sand compatriots that
namespaces, templates, and exceptions aren't necessarily all they're
cracked up to be...
Scott
Friday, September 14, 2001
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.
- 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
this scenario, when calling template functions that take
complex
proxy is not converted to a complex
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.
Monday, September 3, 2001
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.
- 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
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.
Tuesday, August 21, 2001
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
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
Friday, August 3, 2001
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
now available in PDF at my web site:
http://www.aristeia.com/Papers/CUJ_June_2001.pdf.
Scott
Monday, July 30, 2001
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
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
Tuesday, July 17, 2001
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/ |
+---------------------------------------------------+
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/ |
+---------------------------------------------------+
Wednesday, June 27, 2001
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/
+---------------------------------------------------+
- 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
};
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/
+---------------------------------------------------+
Saturday, June 16, 2001
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/ |
+---------------------------------------------------+
- 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/ |
+---------------------------------------------------+
- 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/ |
+---------------------------------------------------+
Tuesday, June 5, 2001
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/ |
+---------------------------------------------------+
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/ |
+---------------------------------------------------+
Sunday, June 3, 2001
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/ |
+---------------------------------------------------+
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/ |
+---------------------------------------------------+
Wednesday, May 23, 2001
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/ |
+---------------------------------------------------+
- 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/ |
+---------------------------------------------------+
Thursday, May 17, 2001
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/ |
+---------------------------------------------------+
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/ |
+---------------------------------------------------+
Tuesday, May 8, 2001
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
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
- 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
Wednesday, May 2, 2001
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
"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
Wednesday, March 28, 2001
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
---------------------------------------------------------------------------
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
---------------------------------------------------------------------------
Friday, February 9, 2001
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
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
Subscribe to:
Posts (Atom)
