Search in Book Reviews

Let me start out straight away and say that the price for this book puts it solidly out of the reach of its declared target readership (students). Possibly this may be another example of McGraw-Hill's crazy pricing policy and that they have another cheaper (but textually identical) version as a student text but I can only go on what I see.

The next problem is that the authors proudly proclaim that this book will teach OO, Windows programming and event driven programming simultaneously. Every book aimed at novices has to rely on a little magic hidden away in header files (even if they are only those for the Standard C++ Library), this one relies on a veritable mountain hidden away. All the authors have done is to provide their own GUI API and make sure that it supports a mouse. Sorry, I do like the idea of allowing programmers to use graphics from day one but I do not consider that to be teaching them Windows and event driven programming.

Much of the book is built on a library of turtle graphics primitives. Again that is a good idea but the programmer is neither learning C++ nor OO when s/he gets a turtle to move around the screen drawing stars etc. This is largely procedural programming in a minimalist turtle graphics language.

Then I come to the irritants that show the authors to be ignorant of the fundamentals of the language. Everywhere their main returns void. If they are as sloppy in accepting student code then their students will end with a flawed grasp of the essentials of programming.

I am sorry to say that this book is typical of academic writers that have very little if any understanding about the way C++ was designed for use. The result is that their students (and readers of their books) finish up with seriously flawed understanding of the art of programming.

Before I finish let me illustrate another example of pure bad programming. On pages 250-260 the authors introduce and develop a class called Volume. This class has a single data member declared as:

const float PI;

Leaving aside for the moment that I hate variables spelled in all uppercase (that name style is for the pre-processor), why is this instance data? Mathematical constants are absolute and not members of objects. You and I both know that this should be a static member of the class.

Next we have the class constructor:

Volume() : PI(3.14159) {}

So now we have some Volume object. Surely 'volume' is a property of a solid (or even liquid). I can envisage using a some form of ABC, or even a mixin to support the concept of volume but my hackles rise at the concept of a free standing class of this kind. It gets worse when you discover that the public members of the class are tri_prism(), rect_prism(), sphere(), cylinder() and cone(). Each returning a float and each with its own set of parameters. This is just stupid and to my mind shows that the authors have no idea about what OO is about.

By the way, they allow serious breeches of data encapsulation by having member functions return non-const pointers to private data. They also do not seem to know about const member functions, nor do they seem to understand anything about copy constructors and assignments.

I wonder who did the technical reviews of the pre-publication text because they should share the blame for something that should never have seen the light of day. I bet they were fellow (and just as ignorant) academics.