One, the authors did not mention which compiler they used to compile their program examples. Many of the programs do not compile in MS Visual C++ 6.0 as written in the text. The authors fail to mention you might have to modify the code to get it run on your compiler. For instance,
cout << fixed;
may have to be replaced with
cout.setf(ios::fixed);
or
cout.setf(ios::fixed, ios::adjustfield);
to run right in your compiler.
They do finally talk about cout.setf in chapter 7 (out of 15). The program example downloads from the website compile; they contain preprocessor directives to make the programs more portable. I guess it never occurred to the authors, while adding those preprocessor directives (which DO NOT appear in the text), that some words about compiler compatibility might be helpful. Fortunately, I have C++ Primer Plus by Mitchell Waite; he addresses the compatibility issues as he teaches the syntax.

Two, I often disagree with the authors' definitions. My favorite example: the statement
x = 5;
changes the value of the variable x to 5. The authors call this a "side effect." Huh? Seems like that's exactly what the programmer intends to do. Usually, I think of side effects as being more subtle than that. More like a function changing the value of a variable parameter to the function because the variable was passed by reference instead of by value (this could catch an unsuspecting programmer by surprise if he/she didn't check the prototype carefully).

Three, some of the "good programming" tips would cause me to fail code inspections at work. This is a good thing, because they would make verification and maintenance a nightmare. Like not initializing variables when they are declared. I guess the authors have never seen weird things happen as an executing program tries to deal with the garbage in an uninitialized variable. Or maybe they just figure this is a good way for you to discover you forgot to initialize a variable before first use. It just might take a while to figure out that's what's going on since the results can be unpredictable and/or bizarre.

I could continue, but I think I've more than made my point. I won't be standing in line to get the second edition when it comes out next year.

The authors mention the ISO/ANSI C++ standard and claim to follow it "wherever possible" (sic). However, they make so many false statements that I seriously doubt that they have ever consulted the ISO/ANSI Standard documents, or any of the excellent text books on modern C++ design and coding practice (Cline, Meyers, Sutters.)

I believe (and I'm not alone) that in a modern C++ course std::vector should be introduced before arrays, and std::string before const char*. Not only are they safer, they are also *a lot* easier to use, and make it possible to come up with more interesting programming exercises than the endless array of meaningless numerical computations. Unfortunately, many instructors and authors consider std::vector and std::string to be "advanced topics", and torture their students and readers with the old stuff they had to learn themselves ten or more years ago. The authors belong to this category, I'm afraid: they learned C, and think that they know C++.

Let's have the book speak for itself.

Page 28:

"While C++ allows declarations and statements to be intermixed, we believe that functions should be organized for readability. Therefore, we continue to follow the C organizational concept that places declarations first in a function, followed by its statements."

On a related note, on page 40 the authors write:

"One final point about initializing variables when they are defined: Although the practice is convenient and saves you a line of code, it also can lead to errors. It is better, therefore, to initialize the variable with an assignment statement at the proper place in the body of the code. This may take another statement, but the efficiency of the program is exactly the same, and you will make fewer errors in your code."

(My comments:) It is commonly accepted by knowledgeable C++ programmers that the practice of declaring variables near the point of their first use in one of the things that makes C++ a better C. It is the old style that leads to errors (forgetting to initialize variables) and maintenance problems (variables that are no longer used, but are still in the declaration section). Furthermore, it is considered good style to prefer initialization ( int sum = 0; ) over subsequent declaration and assignment ( int sum; sum = 0; ). The former is always more efficient, and the difference can be substantial when dealing with large objects for which construction is expensive. You may argue that this is of no concern for beginning C++ programmers, but I disagree; habits, both good and bad, form early.

--

From the code example on page 363: bool binarySearch (int list[ ], int end, int target, int &locn){ ... }

(My comments:) The first argument should be const-qualified: const int list[ ]

Not only does this protect the programmer from inadvertently changing any of the values stored in the array; it also makes it possible to use the function with const int[] arguments (which would fail to compile with the original code). The const keyword is an important asset of the C++ language, and students should be trained to use it properly from the beginning. Using the Standard Template Library will drive programmers who are not aware of const-correctness issues insane. The book is extremely sloppy in the const-correctness area.

--

Page 119:

"If a function has not been declared or defined before it is used, C++ will assume that you will provide that information when you link the program. Since there are no specifications, C++ will also assume that the return type is integer and that the parameter types correctly match the formal definitions."

(My comments:) This is not true: in C++, functions have to be declared before they are used, and there is no such thing as 'implicit return type int'. C++ really is different from K&R-style C.

--

On page 195, the following insight is highlighted:

"The else-if is an artificial C++ construct that is only used when

1. The selection variable is not an integral, and

2. The same variable is being tested in the expressions."

(My comments:) No further questions here, your honor.

--

It gets really interesting when the authors express their ideas on Object-Oriented programming. They claim that Object-Oriented programming is just a different view, but that the implementation is exactly the same as in structured programming. They are probably misguided by their own example of an elevator simulation program (in the chapter on classes), which is simply a structured program wrapped in a class, and has nothing to do with OO.