The first thing you need to do is to read the title carefully. If you do so (which I confess I did not at first) you will realise that this is a book about writing software that either tests equipment or measures some aspect of it. That will also suggest that it is a book aimed at engineers. Such a book should, to my mind, be a collaboration between a good programmer and an experienced practitioner in the application domain. The fact that Hewlett-Packard both endorses this book (it is one of their Professional Books series) and employs the author suggests that the book will be well written and authoritative.

Now I am not qualified to determine how well this book addresses the needs of the application domain so I have to address my review at the programming side of the book. As you will see, my conclusion is that the author needs serious help with his programming.

However let me start by tackling a small nit. The book comes with a CD though the text refers to a floppy disk. Do not be deceived, the CD is no more than a floppy disk, its contents would happily fit on one. It would be nice if publishers provided some added value (even if it was only a copy of the bible, or the complete works of Shakespeare) when electing to distribute the machine readable material on a CD.

A rather bigger nit is that the book does not have an index. I discovered this when I wanted to refer to the textual material referred to in one of the comments in the source code on the CD. The lack became more serious when I wanted to locate the definition (presumably a

typedef

) for the author's type

error

. The author may assume that all readers will read his book linearly and always remember where previous definitions etc. are found. Even readers who read from the start and never skim will have difficulty with the absence of an index.

Let me now move to the body of the text. The early chapters introducing OO and C++ skim very rapidly over the subject. In other words the reader must either be a competent programmer with prior knowledge of C++ or will have to buy one or more other books. That may be an opinion but I think that the reader needs more than 15 pages on OO and 23 on OO in C++ (or else does not need these at all).

Let me turn now to the author's design and implementation of a complex number class. I choose this because if there is any single value based type that an engineering author should be familiar with this is it. Of course it is an example of re-inventing the wheel as the Standard C++ Library has had such a class for years (even the change to make it a template class so that you can have different degrees of precision does not fundamentally invalidate this). You will understand my problems with this book if you examine the following extract from the relevant header file:

// Constructors/Destructors
Complex(); // Default Constructor
Complex(const Complex&); // Copy Constructor
Complex(double realPart, double imagPart); // Store real and imaginary parts
Complex(double radius, double angle, int);
Complex(double realPart); // Store real part
virtual ~Complex();

Why not provide a single constructor such as:

Complex(double realPart =0, double imagPart =0); // Store real and  imaginary parts

Among the other advantages is that it documents the default values for the parameters.

There is no need for a copy constructor (nor a copy assignment), and in a true value based class I would prefer to leave the compiler to do the right thing (it will probably do it better anyway). That leaves the constructor that supports (modulus, argument)-representation of complex values (why didn't the writer use the proper names for these instead of

radius

and

angle

?). I hate the anonymous parameter hack to provide overloading when the true parameter set has an identical set of types to some other overload member. Here it is unnecessary as a more appropriate choice would be to use some user defined type such as Radians or Degrees:

class Degrees {
double angle;
public:
Degrees(double d =0.0): angle(d) {}
operator double() { return angle;}
};

I think does the job - a true type that behaves like a built- in

double

. That would also have the added benefit of making clear what the angle is measured in.

Finally we have the decision to provide a virtual destructor in an essentially value based class. This must be wrong. If the designer gets the interfaces right inheritance would be silly. The only conceivable room for variation is in the precision of the arithmetic and that cannot be provided via inheritance.

1) The accessor functions.

The author makes all these inline. As his implementation includes support for (modulus, argument)-representation that means that some of his accessors are more than trivial and therefore should not be inline.

2) arithmetic operators.

His code shows he knows that the so called compound operators (+=, etc.) are more fundamental and can be used to implement the ordinary operators. So why does he keep the ordinary operators as members? Two of these are symmetric functions (+ and *) and should be provided in global space (or when possible, in a namespace). The other two need more extensive thought including handling a left-hand operand being of a type other than

Complex

. The author's implementation of the arithmetic operators falls into some of the standard traps that are covered in any responsible C++ training course (even those providing operators as friends)

3) Conversion operator

Finally we have a disastrous provision of a conversion operator (

operator double

) which opens the floodgates to a vast range of errors. There simply is no unique logical conversion from a complex number to a real number. Indeed this flaw is highlighted by the source on the CD actually implementing a different conversion from the one selected in the book.

If any member with experience in the application domain this book addresses would like to review the book from that perspective I would be happy to send them the review copy.