C++ in a Nutshell
by Ray Lischner

This errata page lists errors outstanding in the most recent printing.

If you have technical questions or error reports, you can send them to
booktech@oreilly.com.  Please specify the printing date of your copy.

This page was updated April 26, 2007.

Here's a key to the markup:
	[page-number]: serious technical mistake
	{page-number}: minor technical mistake
	<page-number>: important language/formatting problem
	(page-number): language change or minor formatting problem
	?page-number?: reader question or request for clarification



Confirmed errors:


{35}  Last paragraph of prose;
The paragraph states that the call to std::div in example 2-12 captures the return
value by const reference, eliminating the need for a temporary structure and for the
value of std::div to be returned by value (copying the structure).

In fact, std::div returns a structure by value already, and capturing the return to a
const reference just causes the compiler to generate a temporary on the stack, copy
the return value of std::div to the temporary, then bind the reference to the
temporary.



[37]  top of page;
The discussion about vectors of references, and especially the notion of "trying to
use a vector<int&> with your compiler" is flawed.  References do not have value
semantics so they could not be used with the vector class even if references of
references were valid.  It would be better to use a map<int&> as an example.
Obviously STORING the reference as a pointer in the vector would work around the fact
that references don't have value semantics, but the prose in the section is flawed in
the discussion.
AUTHOR: There are many reasons why you cannot use references in a container.
Chris is correct that the value semantics are an important one,
arguably more important than the reference-to-reference problem. I
should have chosen a different example for illustrating the problem of
reference-to-reference and ways of coping with them.



(59)  Expression Rules section;
This section gives the semantics of many operators (e.g. pointer->name-expr ===
(*pointer)).name-expr), but doesn't point out that these semantics only hold for
built-in types.  User defined types can overload these operators to do whatever the
user wants...
AUTHOR: The descriptions on pages 61-82 apply only to the built-in operators.