During the course of the past year, my most popular C++ seminar has been my
new one on making effective use of C++ in an embedded environment. For
whatever reason, I've offered this as an open-enrollment course several
times in Europe, but never as an open-enrollment course in the USA. Until
now. On Monday, December 15, I'll be presenting this seminar in Beaverton,
Oregon, and if you're working with embedded systems and are interested in
how to use C++ in that environment or how to *better* use C++ in that
environment, I encourage you to consider attending.
For details on the seminar, consult the web page at
http://cpd.ogi.edu/courseSpecific.asp?pam=1399. I hope to see you in
December.
Scott
Wednesday, October 22, 2003
Tuesday, October 7, 2003
Updated Book Errata Lists
EC++ and MEC++ are up for new printings (the 15th and 17th, respectively,
on the off chance you care), so I took the opportunity to update the errata
lists for both them and ESTL. You'll find the updated errata lists at the
usual locations:
EC++: http://www.aristeia.com/BookErrata/ec++2e-errata_frames.html
MEC++: http://www.aristeia.com/BookErrata/mec++-errata_frames.html
ESTL: http://www.aristeia.com/BookErrata/estl1e-errata_frames.html
Below I've appended the new entries for each list. These are easier to
peruse to see if you care about any of the changes.
I haven't actually made the changes for the new printings yet, but when I
do, I'll update the EC++ and MEC++ errata lists to show the fix dates for
the changes that will appear in the next printings. That should be done by
next week, so check in with the errata lists then if you're interested in
how the new printings will differ from the current ones.
Scott
PS - Interested in a glimpse at new functionality being added to C++'s
standard library? Check out
http://std.dkuug.dk/jtc1/sc22/wg21/docs/library_technical_report.html
****************************************************
* NEW ENTRIES FOR EFFECTIVE C++ *
****************************************************
Errata:
DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
9/18/03 ss 99 The function returnStudent is dangerously
declared on this page, because it returns a
reference to what could be a temporary object.
For details, consult FAQ 32.08 of C++ Faqs by
Cline, Lomow, and Girou.
8/13/03 mc 222 There is more to the Singleton pattern than I
describe in this Item. In particular, I make no
mention of how to limit instantiation of a
singleton class to one. The technique is
clearly related to Singleton, but as mc notes,
"You can't spell 'singleton' without spelling
'single.'"
Interesting Comments:
DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
6/17/03 wk 77 There are pathological cases where pass by value is
accomplished by instantiations of "copying constructors"
rather than by the class' copy constructor. For details,
consult the
href="http://groups.google.com/groups?hl=en&lr=lang_en|lang_de&ie=UTF-8&oe=UTF-8\
&threadm=3eba7ee4%40news.microsoft.com&rnum=1&prev=/groups%3Fsourceid%3Dnavclien\
t%26ie%3DUTF-8%26oe%3DUTF-8%26q%3DI%2Bfound%2Bevidence%2Bto%2Byour%2Beducated%2B\
guess%2Bmostly%2Bin%2B12.8%252F8%2B(recursive"
target="_top">comp.lang.c++.moderated thread on the topic.
7/ 1/03 sv 108 The last sentence says you *must* use overloading, but if
you are willing to change the API, you have other choices,
e.g., you could pass a vector of values.
5/19/03 sdm Item 34 Because it's not possible to declare nested classes
without defining the class in which they are nested,
nested classes can lead to unnecessary compilation
dependencies. An alternative design is to unnest the
class and include both classes in the same namespace.
However, this is viable only when the nested class is
public, because namespaces offer no encapsulation.
6/11/03 sf Item 38 A drawback to the advice in this Item is that callers
going through the derived class interface must specify
all parameter values; the default parameter values
apply only via the base class interface. An
alternative design is to respecify the (same) default
value in each derived class, but then if the default is
changed in the base class, all derived classes must be
updated with the new value, too.
8/13/03 mc Item 43 Slightly edited, mc writes: "You are not completely
fair in this Item. The trick with auxillary classes is
needed in order to allow overloading of any
functionalities involved in the name clash, but the
clumsiness and the lack of virtual behavior are not
valid arguments. Explicit qualification is clumsy, but
so is explicit upcasting of pointers (it takes more
than one line, compare upper page 196 with middle page
197). So clumsiness is not the argument here. Moreover,
calling pls->draw(); on page 197 would still be an
error just as on page 196, so don't bad-mouth the first
approach on that account. Reversely, applying the
pointer upcast trick on page 196 instead would conserve
the virtual behavior. So the only argument left is that
only one of the methods can be overloaded, the other
will be lost (this is reason enough to apply the
technique you offer). In the end, there's no error in
your text, but I think that the code and the
formulation makes the reader focus on the wrong aspects
of the problem."
****************************************************
* NEW ENTRIES FOR MORE EFFECTIVE C++ *
****************************************************
Errata:
DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
! 4/30/03 mh 209 RCIPtr::init should test oldValue against NULL
before dereferencing it.
6/ 8/03 sdm 265 Bad line break: AbstractA-nimal ==> Abstract-
Animal
! 6/ 7/03 mh 266 2nd and 3rd paras discuss the assumption that
base classes have no data. The correct assumption
is that *derived* classes have no data.
Interesting Comments:
DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
6/ 3/03 sxb 202 The bug for these pages reported by ct on 9/16/98 is
206 incorrect, because when RCPTR::operator= is called with
a raw pointer as an argument (e.g., p->next), a
temporary RCPtr will be created from the raw pointer,
hence the reference count won't go to 0 when
removeReference is called. (I'll keep the code in the
book as is, because it behaves correctly, and I don't
want to mess with code in the book any more often than
I have to.)
****************************************************
* NEW ENTRIES FOR EFFECTIVE STL *
****************************************************
Errata:
DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
8/ 1/03 lfr 51 In 2nd-to-last para, "unsigned integral value"
==> "unsigned integral type"
5/19/03 drm 168 My claim that "Declaring operator() const in
predicate classes is necessary for correct
behavior, but it's not sufficient" is too strong.
E.g., it would be safe to modify data members that
don't affect the outcome of the predicate. Reword.
DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
9/30/03 mp 188 In the operator() implementation at the top of the page, it
might be preferable to write the test this way,
return lowVal < val && val < highVal;
so that val is both numerically and *physically* between
the bottom of the range on the left and the top of the
range on the right. mp finds this clearer and also nearer
to the mathematical notation "lowVal < val < highVal." (mp
attributes this idea to either Steve Maguire's "Writing
Solid Code" or "Debugging the Development Process."
5/16/03 drm Item 26 "The advice of this Item seems kind of strong. Counting
in my last bit of code: 49 const_iterators, 3 iterators, 0
problems (so far). I think a better slant to the Item
might be: be careful, const_iterators have certain
restrictions. I don't see that those restrictions
necessarily lead to the recommendation to prefer iterator."
on the off chance you care), so I took the opportunity to update the errata
lists for both them and ESTL. You'll find the updated errata lists at the
usual locations:
EC++: http://www.aristeia.com/BookErrata/ec++2e-errata_frames.html
MEC++: http://www.aristeia.com/BookErrata/mec++-errata_frames.html
ESTL: http://www.aristeia.com/BookErrata/estl1e-errata_frames.html
Below I've appended the new entries for each list. These are easier to
peruse to see if you care about any of the changes.
I haven't actually made the changes for the new printings yet, but when I
do, I'll update the EC++ and MEC++ errata lists to show the fix dates for
the changes that will appear in the next printings. That should be done by
next week, so check in with the errata lists then if you're interested in
how the new printings will differ from the current ones.
Scott
PS - Interested in a glimpse at new functionality being added to C++'s
standard library? Check out
http://std.dkuug.dk/jtc1/sc22/wg21/docs/library_technical_report.html
****************************************************
* NEW ENTRIES FOR EFFECTIVE C++ *
****************************************************
Errata:
DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
9/18/03 ss 99 The function returnStudent is dangerously
declared on this page, because it returns a
reference to what could be a temporary object.
For details, consult FAQ 32.08 of C++ Faqs by
Cline, Lomow, and Girou.
8/13/03 mc 222 There is more to the Singleton pattern than I
describe in this Item. In particular, I make no
mention of how to limit instantiation of a
singleton class to one. The technique is
clearly related to Singleton, but as mc notes,
"You can't spell 'singleton' without spelling
'single.'"
Interesting Comments:
DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
6/17/03 wk 77 There are pathological cases where pass by value is
accomplished by instantiations of "copying constructors"
rather than by the class' copy constructor. For details,
consult the
href="http://groups.google.com/groups?hl=en&lr=lang_en|lang_de&ie=UTF-8&oe=UTF-8\
&threadm=3eba7ee4%40news.microsoft.com&rnum=1&prev=/groups%3Fsourceid%3Dnavclien\
t%26ie%3DUTF-8%26oe%3DUTF-8%26q%3DI%2Bfound%2Bevidence%2Bto%2Byour%2Beducated%2B\
guess%2Bmostly%2Bin%2B12.8%252F8%2B(recursive"
target="_top">comp.lang.c++.moderated thread on the topic.
7/ 1/03 sv 108 The last sentence says you *must* use overloading, but if
you are willing to change the API, you have other choices,
e.g., you could pass a vector of values.
5/19/03 sdm Item 34 Because it's not possible to declare nested classes
without defining the class in which they are nested,
nested classes can lead to unnecessary compilation
dependencies. An alternative design is to unnest the
class and include both classes in the same namespace.
However, this is viable only when the nested class is
public, because namespaces offer no encapsulation.
6/11/03 sf Item 38 A drawback to the advice in this Item is that callers
going through the derived class interface must specify
all parameter values; the default parameter values
apply only via the base class interface. An
alternative design is to respecify the (same) default
value in each derived class, but then if the default is
changed in the base class, all derived classes must be
updated with the new value, too.
8/13/03 mc Item 43 Slightly edited, mc writes: "You are not completely
fair in this Item. The trick with auxillary classes is
needed in order to allow overloading of any
functionalities involved in the name clash, but the
clumsiness and the lack of virtual behavior are not
valid arguments. Explicit qualification is clumsy, but
so is explicit upcasting of pointers (it takes more
than one line, compare upper page 196 with middle page
197). So clumsiness is not the argument here. Moreover,
calling pls->draw(); on page 197 would still be an
error just as on page 196, so don't bad-mouth the first
approach on that account. Reversely, applying the
pointer upcast trick on page 196 instead would conserve
the virtual behavior. So the only argument left is that
only one of the methods can be overloaded, the other
will be lost (this is reason enough to apply the
technique you offer). In the end, there's no error in
your text, but I think that the code and the
formulation makes the reader focus on the wrong aspects
of the problem."
****************************************************
* NEW ENTRIES FOR MORE EFFECTIVE C++ *
****************************************************
Errata:
DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
! 4/30/03 mh 209 RCIPtr
before dereferencing it.
6/ 8/03 sdm 265 Bad line break: AbstractA-nimal ==> Abstract-
Animal
! 6/ 7/03 mh 266 2nd and 3rd paras discuss the assumption that
base classes have no data. The correct assumption
is that *derived* classes have no data.
Interesting Comments:
DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
6/ 3/03 sxb 202 The bug for these pages reported by ct on 9/16/98 is
206 incorrect, because when RCPTR::operator= is called with
a raw pointer as an argument (e.g., p->next), a
temporary RCPtr will be created from the raw pointer,
hence the reference count won't go to 0 when
removeReference is called. (I'll keep the code in the
book as is, because it behaves correctly, and I don't
want to mess with code in the book any more often than
I have to.)
****************************************************
* NEW ENTRIES FOR EFFECTIVE STL *
****************************************************
Errata:
DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
8/ 1/03 lfr 51 In 2nd-to-last para, "unsigned integral value"
==> "unsigned integral type"
5/19/03 drm 168 My claim that "Declaring operator() const in
predicate classes is necessary for correct
behavior, but it's not sufficient" is too strong.
E.g., it would be safe to modify data members that
don't affect the outcome of the predicate. Reword.
DATE
REPORTED WHO PAGES WHAT
-------- --- ----- -----------------------------------------------------------
9/30/03 mp 188 In the operator() implementation at the top of the page, it
might be preferable to write the test this way,
return lowVal < val && val < highVal;
so that val is both numerically and *physically* between
the bottom of the range on the left and the top of the
range on the right. mp finds this clearer and also nearer
to the mathematical notation "lowVal < val < highVal." (mp
attributes this idea to either Steve Maguire's "Writing
Solid Code" or "Debugging the Development Process."
5/16/03 drm Item 26 "The advice of this Item seems kind of strong. Counting
in my last bit of code: 49 const_iterators, 3 iterators, 0
problems (so far). I think a better slant to the Item
might be: be careful, const_iterators have certain
restrictions. I don't see that those restrictions
necessarily lead to the recommendation to prefer iterator."
Upcoming Talk at OGI next Thursday (Oct. 16)
The Oregon IEEE Computer and Communications societies asked me to be their
October speaker, so next Thursday (October 16) I'll be giving a talk on
"The Keyhole Problem" at OGI in Beaverton. You can find all the details at
http://www.ieee-or.org/events/EventDetails.asp?eventid=187 and
http://cpd.ogi.edu/class.asp?n=04-IEEE-1016
I hope to see you at OGI on Thursday evening!
Scott
October speaker, so next Thursday (October 16) I'll be giving a talk on
"The Keyhole Problem" at OGI in Beaverton. You can find all the details at
http://www.ieee-or.org/events/EventDetails.asp?eventid=187 and
http://cpd.ogi.edu/class.asp?n=04-IEEE-1016
I hope to see you at OGI on Thursday evening!
Scott
Thursday, October 2, 2003
"Effective XML" is now out
The second book in my Effective Software Development Series has just come
out, Elliotte Rusty Harold's "Effective XML." Many books have been
published that mimic the format of my "Effective" books, but this is the
first one to come out where I offered advice to the author on how to better
make the book "work." Rusty is an established author, so he knows how to
write, and his knowledge of XML is outstanding. I think you'll find that
"Effective XML" offers exactly what the subtitle promises: "50 Specific
Ways to Improve Your XML."
You can read more about the book at
http://www.awprofessional.com/catalog/product.asp?product_id={8E524FFF-F58B-4C5A\
-BBC8-6E02DC159996}&session_id={0994EFB6-20AC-468B-8C72-2603CCFD9EBF}
Scott
out, Elliotte Rusty Harold's "Effective XML." Many books have been
published that mimic the format of my "Effective" books, but this is the
first one to come out where I offered advice to the author on how to better
make the book "work." Rusty is an established author, so he knows how to
write, and his knowledge of XML is outstanding. I think you'll find that
"Effective XML" offers exactly what the subtitle promises: "50 Specific
Ways to Improve Your XML."
You can read more about the book at
http://www.awprofessional.com/catalog/product.asp?product_id={8E524FFF-F58B-4C5A\
-BBC8-6E02DC159996}&session_id={0994EFB6-20AC-468B-8C72-2603CCFD9EBF}
Scott
Subscribe to:
Posts (Atom)
