Search in Book Reviews

My problem with this book is where to start. It is a large volume from a reputable publisher and so I suppose my first mistake was in expecting it to be a good book. This expectation was strengthened by the endorsements inside the front cover from two 'Senior Software Engineers' from reputable companies (Motorola and GE Marquette Medical Systems, Inc). From there onwards it was all down hill.

Under the heading '

How This Book Is Organised' I got my first sense that all might not be well. The author states that experienced C++ programmers will find parts 3& 4 will be most useful, experienced C programmers will find part 2 useful and those with experience of other high level languages should start with part 1. Those who are seeking to learn to program should start with chapter 2 read to the end of part 1 then go back and read chapter 1. In other words the author is claiming that this book will be useful to absolutely everyone. Well not quite because he missed all those who know they are not yet experienced but already know how to program. If you believe that a single book can meet all these objectives, you must believe in fairies.

At this point I broke off and had a look at www.amazon.com and www.amazon.co.uk. The US site gave the book an average of over four stars (out of five) and all but one of the seven reader reviews gave the impression that this was an outstanding book. By contrast there was a single very brief 'review' on the UK site that concluded with 'DO NOT BUY THIS BOOK'. This is the only statement with which I can agree, but read on to find out more.

Let me start with the presentation. The page layout has wide outside margins, however code intrudes into these when whoever was responsible decided that it suited them, even when long lines were a direct consequence of placing multiple statements on a single line. Otherwise source code was sometimes indented (slightly more than the first line of a text paragraph) and sometimes it was not indented. I could find no consistent rule to determine which would be chosen. This is not that important but it goes to show the attitude of those directly responsible for publication. (I have since ascertained from the author that part of the problem was a relatively late change to the page layout by the publishers leaving him with the problem of patching up the display of code. This is one of numerous problems authors encounter when the elect to write for publishers who operate on tight and immovable deadlines.)

Chapter 2 is supposedly the start of learning C++. On the second page of that chapter we find the author's version of 'Hello World'. Here it is (to save space, I have left out the comments. However the layout is exactly his, apart from the three output statements that have wrapped)

#include<iostream>
#include<cmath>
using namespace std;
const double PI = 3.1415926;
int main(void)
{
 double x = PI, y=1, z;
 cout<< "Welcome to the C++ world!"<< endl;
 z = y + 1;
 y = pow(x, z);
 cout<< "In that world, pi square is "<< y<<
 endl;
 cout<< "Have a nice day!"<< endl;
 return 0;
}

This is one of the very few pieces of code in the book that is free from error (I think). The author then writes:

Do not worry if this program looks obscure. By the end of this chapter, you will understand every detail (and more).

So let me extract a few of the author"s words:(writing about pre-processor directives)

... but in theory, these directives are not part of the language! In practice, it is the compiler vendors that supply the pre-processors, but in theory, compilers and pre-processors are not related.

Exactly where has the author been for the last dozen years? A quick check on the phases of translation (see 5.1.1.2 in the original C Standard) will give the lie to his claim.

A little later (page 48) we find#include<math>. About half the time he omits the leading 'c' when referencing a C header by its C++ name. Just after that we find:

The last line in this code segment from our first program is the using namespace directive. It is not a pre-processor directive. It instructs the compiler to recognize the code brought in by the header files.

I do not strongly object to that statement at this stage, but as far as I can see, that is all he ever has to say on the subject ofnamespace. Even in the supposedly advanced parts of the book he simply uses that statement as a magic spell. On page 271 he listsnamespaceas a lexical scope but never returns to the issue (well I do not think he does, but I do not have time to read every word of a book as full of errors and omissions as this one).

Towards the bottom of page 50 we find:

Also notice that the symbolic names are in uppercase. It is not necessary, but it is a common programming convention. Another popular convention is to use lowercase, but start the symbol name with two underscore characters:

#define __cplusplus

Note that he never mentions that this convention is specifically for implementers and could cause havoc if used by others as all uses of a double underscore are reserved to the implementer.

At some stage I wanted to check the author's list of keywords and reserved words. I looked in the index. There are no items starting with 'k'. Note that immediately after the list (page 57) he writes 'I do not think you should try to remember all these keywords now'. That, in my opinion, makes an entry in the index rather important. The author also completely ignores the alternative spelling for logical and bitwise operators that have been part of the language for almost a decade.

Let me move on to a few of the advanced aspects, or the lack thereof. As far as I can determine, he makes very little use of the Standard C++ Library, other than iostream he mostly uses the parts inherited from Standard C. We do not get tovirtualfunctions until page 961, just a bit late when you consider that the whole of the second half of this book is supposed to be for experienced C++ programmers. (What do we call a programmer who knows about virtual functions and polymorphism?) Templates are delayed until page 1080, and do not look here for anything even slightly advanced.

Another idiosyncrasy is that the author seems to randomly interchangestructandclass. It is not that the resulting code is 'wrong' just that no experienced C++ programmer I have ever met would use those keywords that way. Why didn't the technical reviewers pick up such non-idiomatic usage?

I think I have written enough. Whatever category of reader you belong to there is nothing in this book for you. It is riddled with errors, the style of C++ would have been bad five years ago and is now dangerously bad (no concept of exception safety). The author"s relaxed writing style may have seduced some first timers into thinking it a good book because they can understand it without too much effort. Unfortunately what they understand is seriously erroneous.

What causes me more concern is those endorsements from two people with the title 'Senior Software Engineer'. Such endorsements explain why many employers restrict what their employees write for public consumption. I have do doubt that anyone endorsing this book (after actually reading it) is seriously deficient in their understanding of C++ and is far below the level of expertise that I would expect from Senior Software Engineers who believe they know enough about C++ to express an opinion.

The publishers need to review their pre-publication processes because books such as this one should not be seen in bookstores. If I was an author of any other book in this series, I would be very concerned because this one will reduce the reputation of the series as a whole.

Let me finish with a final snippet of code from page 532 (again in the author's layout. The ellipsis represents several omitted functions:

Name::Name(char * name)
{ int len = strlen(name);
 contents = new char[len+1];
 if (contents == NULL)
  { cout<< "Out of memory\n"; exit(1); }
 strcpy(contents, name); }
...
Name::~Name()
{ delete contents; }

Think about the implications of that code. A few hints:

1) How do I call a constructor for an array ofconst char(and that is the type of a string literal in C++)?

2) Small issue, but why bother withlen?

3)newdoes not return a null pointer, and has not done so for at least six years.

4)exit()is a C function that should never be called in C++ because it does not clean up the stack.

5)contentsis a pointer to an array and so MUST be destroyed withdelete[].I know that there are those who think it does not matter for fundamental types, but it does because some compilers allocate memory for arrays differently from that for single objects.

6) The layout is weird even if you are trying to save space. (the two line output statement is a single line in the book)