Errata

The sentence
"C++ does introduce a number of new minor improvements to C++"
should read
"C++ does introduce a number of new minor improvements to C"

When discussing indentation example 3-1 is referred to. Example 3-1 is the "Hello
World" program on page 25, not the code on page 30 to which the discussion refers.

"Now let's take a look at the 'Hello World' program (Example 1-1)"
should say Example 3-1, not 1-1.

grammar:
"what a object" s/b "what an object"

Note from the Author or Editor:
a object -> an object

"These names are depreciated ..."
SHOULD BE
"These names are deprecated ..."

The code is correct, but the use of

#include <assert.h>

is old fashioned. This should be changed to the more modern:

#include <cassert>

Reference to 'Chapter 1' should be 'Chapter 10'?

{83/84}
In the example program, the loop would either never execute or loop
infinitely because none of the variables the test expression is based
on, are changed in the body of the loop.
Is this intentional?

Note from the Author or Editor:
Page 73: Chapter 1 -> Chapter 10.

Page 83:84: The submission is incorrect. The program works.

"...Example 6-2 computes all the Fibonacci numbers..."

SHOULD BE:

"...Example 6-1 computes all the Fibonacci numbers..."

Doesn't entirely fit in any category, but it would be helpful if the value of a
quarter, a dime, a nickel & a penny were listed (particularly a dime & a nickel)
-- we're not all used to using US currency day-to-day and don't necessarily know
what the names mean.

Note from the Author or Editor:
Change: quarter -> quarter(25<cent>), dime -> dime(10<cent>), nickel -> nickel(5<cent>), penny -> penny(1<cent>)

<cent> -- The cent character.

Add as first line:

#include <assert.h>

Reference to 'Chapter 1' should be 'Chapter 7'?

Note from the Author or Editor:
Chapter 1 -> Chapter 7.

"what it take" should be "what it takes"

Note from the Author or Editor:
Submitter is correct. Change take->takes.

Reference to 'Chapter 1' should be 'Chapter 7'?

Note from the Author or Editor:
Chapter 1 -> Chapter 7.

your refine
your remove

SHOULD BE

you refine
you remove

The trailing '2' subscript used for the binary numbers should be smaller.
The font is confusing as at first sight it appears that the '2' is the last
digit of each binary number.

Note from the Author or Editor:
Change 2 to a subscript.

Answer 11-2 and Answer 11-3 should read Answer 11-1 and Answer 11-2
respectively.

SHOULD BE:
Change "Answer 11-2" to "Answer 11-1"
Change "Answer 11-3" to "Answer 11-2"

The last code fragment on page 181 shows the definition of a union. However, it
appears to be missing a necessary semicolon after the closing brace. That is,

union value {
long int i_value;
float f_value;
}

should instead be,

union value {
long int i_value;
float f_value;
};

"In this example we are define..."
should read
"In this example we are defining..."

Reference to 'Chapter 1' should be 'Chapter 11'.

Note from the Author or Editor:
Reader is correct.

"inline int stack_pop(struct stack&the_stack)" should read "inline int
stack_pop(struct stack& the_stack)" (needs a space). The function appears correctly
on page 194.

The 'assert' expression contains a '<=' operator when it should be '<'.
It is printed correctly when the function re-appears in the full listing
on p.194.

Note from the Author or Editor:
Reader is correct.

The 'assert' expression contains a '<=' operator when it should be '<'.
It is printed correctly when the function re-appears in the full listing
on p.194.

Note from the Author or Editor:
Reader is correct.

Reference to 'Chapter 1' should be 'Chapter 9'.

Note from the Author or Editor:
Reader is correct.

Now the we can initialize our variable using the constructor:

SHOULD BE:
Now we can initialize our variable using the constructor:

Don't think that the comment for 'int *thing_ptr' should say '(see Figure
15-2B)'. Figure 15-2A is the best figure that describes both this decla-
ration and the one for 'int thing'.

Note from the Author or Editor:
Remove (see Figure 15-2a) and (see Figure 15-2b)

Comment for '*thing_ptr = 5' should probably say '(See Figure 15-2C)'
although this still is not ideal because the figure shows '*thing_ptr = 6'.

Note from the Author or Editor:
Change
*thing_ptr = 5;
to
*thing_ptr = 6;

(Two places)

Reference to 'Chapter 1' should be 'Chapter 12'.

Note from the Author or Editor:
Reader is correct.

in the for loop the variable "current" is initialized with zero.
After each run it is assigned the variable "number_of_entrys" which is never changed...

The code fragement should read:

for (current = 0; current < number_of_entries; ++current) {
list_ptrs[current] = &list[current]; }

// Sort list_ptrs by zip code

(And end-of-string('') is store in to terminate the string.)

SHOULD BE:

(And end-of-string('') is stored in to terminate the string.)

At the top of the page, "The format of the READ call is:" is at the left margin.
However, the corresponding paragraphs for the WRITE and CLOSE calls are not aligned to the left margin.

In parenthesis '(the pstd::printf family)' should read
'(the std::printf family)'

Note from the Author or Editor:
Reader is correct.

...you'll see that it the number of bytes...

SHOULD BE:
...you'll see that the number of bytes...

Second paragraph: Reference to 'parameter #4' should be 'parameter
#3'. Third paragraph: First sentence starts 'Since every almost
every other standard C...'. Should obviously be 'Since almost every ...'

Note from the Author or Editor:
Change

number of elements to read (parameter #4)

to

number of elements to read (parameter #3)

"detects the type of the variable and performs the approbate conversion"
should be:
"detects the type of the variable and performs the appropriate conversion"

Line numbers are all wrong. Should say:
'At line 31 the data was good, but when we reached line 32, the data
was bad, so the error is located at line 31 ...'

Note from the Author or Editor:
Reader is correct.

Also the code on page 287/line 31 should be indented correctly.

Interactive gdb session suggests repeatedly using 'step'.
'next' would probably be a better suggestion (as used previously on p286)
because gdb starts diving into the stdc++ library.

Note from the Author or Editor:
Page 291/change all "step" to "next".
Page 293-296 same thing.

An extra 'for (i = 0; i < 10; ++i)' has been printed at the end of the code.

Note from the Author or Editor:
Reader is correct.

"using pointers to go through an array is generally faster using an index, ..."
should be:
"using pointers to go through an array is generally faster than using an index, ..."

When adding up the values of the two fixed-point numbers the external representation
is 69.12 while the internal representation is 6192.
The internal representation should be 6912.

"so we must cast fixed_exp do a double"
should be:
"so we must cast fixed_exp to a double"

return (fixed_pt(oper1.value + oper2.value);

Should be:

return (fixed_pt(oper1.value + oper2.value));

inline fixed_pt operator - (const fixed_pt& oper1, const double oper2)
{
return (fixed_pt(-oper1.value - fixed_pt::double_to_fp(oper2));
}

should be:

inline fixed_pt operator - (const fixed_pt& oper1)
{
return (fixed_pt(-oper1.value));
}

Change "Cal Tech" to "Caltech".
The nickname for the California Institute of Technology is "Caltech".
Visit http://www.caltech.edu/ to verify.

before_ptr = first_ptr;

should be

after_ptr = first_ptr;

> insert_ptr->previous_ptr->next_ptr = new_ptr
>You can see this operation represented graphically in Figure 20-9
This should refer to 'Figure 20-10'

> insert_ptr->previous_ptr = new_ptr
>This operation is represented graphically by Figure 20-10.
This should refer to 'Figure 20-11;

Note from the Author or Editor:
Reader is correct.

"Our basic stack is defined in Example 13-1."

The example should be 13-2, not 13-1.

the box on the right in the second row of Figure 21-3 should read "office" instead of "garage"

// Number if items in the array
Should read
// Number of items in the array

hard fighting involving tanks, motors, and heavy artillery
would make more sense as:
hard fighting involving tanks, mortars, and heavy artillery

Note from the Author or Editor:
Reader is correct.

#include <algorthem>;
should be
#include <algorithm>;

Inserting an item into a map is a little trickier that inserting one
should be -
Inserting an item into a map is a little trickier than inserting one
("than" instead of "that")

Thing were probably simple before...
should be -
Things were probably simple before...

Let's first take a look at an example of what not do to.
should say -
Let's first take a look at an example of what not to do.
(switch "to" and "do")

"class _electrice_motor : public generic_locomotive"
should be:
"class _electric_motor : public generic_locomotive"

"...to a difficult code resue problem..."

SHOULD BE:

"...to a difficult code reuse problem..."

defualt
should read
default