[Home Page] - [Reviews Main]

Object-Oriented Programming Using C++ (2ed) by Ira Pohl Not Recommended

ISBN: 0 201 89550 1       Publisher: Addison-Wesley       Pages: 543pp       Price: £30-95

Categories:   object oriented

Reviewed by Francis Glassborow in C Vu 9-4 (May 1997)

Life is not long enough for a reviewer to read a book such as this from cover to cover, that is the job of a technical reviewer who gets some payment for the job. I have to look for evidence that the author knows enough so that I can trust the quality of those parts that I skip.

Leaving aside that the author's description of OOP does not coincide with mine I have to ask why a book that claims to be about OOP in C++ spends so much time introducing the procedural C++ style.

Some of the clues as to quality are little details that experienced C++ programmers would almost certainly do differently. Take for example, the authors very thin my_string class. Apart from the constructors and destructor the author only provides three member functions: void assign(const my_string&), void print() const, void concat(const my_string&, const my_string&). Look very carefully at that list and ask yourself what is missing (the class use a pointer to handle strings by dynamic allocation of exactly enough memory for a null terminated array of char).

Bingo! There is no copy assignment operator. Whatever the author's justification for the other design decisions the class is fatally flawed in a way that no thoughtful and experienced C++ programmer could pass (who did the technical review? If they let this through they did not do their job).

The next suspicious element is the lack of a parameter in the print() function. Inspection of the inline body reveals:

cout << s << endl;
Leaving aside the issue of whether it should be inline, why assume that the user will want to print to cout and will want to automatically add a new line character. Note that there is no other read-access function available.

Examining the rest of the code reveals another eccentricity in the author's heavy use of the assert macro. Don't get me wrong, I think that checking pre- and post-conditions is important but when I see code such as:

s = new char[len + 1];
assert(s != 0);
I start to wonder. First, correctly behaving modern C++ compilers throw an exception rather than return a null pointer when an out-of-memory condition occurs and second I would like an opportunity to handle the problem as the application programmer even if I do not have exceptions available.

What makes this worse is that elsewhere the author has such code as:

 cin >> size;
assert(size>0);

Now let me turn to the author's polynomial class where he introduces a whole gamut of operators through friend declarations. Now I believe that this is a poor design but the clincher is:

friend polynomial& operator += (const polynomial& a, const polynomial& b);
He leaves the implementation as an exercise for the reader. Poor reader, quite apart from the fact that no experienced implementor of value based classes would elect friendship for this particular operator (it is a natural for member function as the lhs should be of the correct class type) how do you manage an assignment to a const qualified left-hand operand?

One final example:

 union int_dbl {
 int i;
 double x;
} n={0};
 n.i= 7;

What makes matters worse is that despite the acknowledged danger, the author continues to use unions for type punning.

The above are not isolated instances but examples of the problems that permeate the entire book.

I guess the technical reviewers trusted the reputation of the author. They should not have done. I suggest that the publishers immediately withdraw this book and get a proper, in depth technical review done. At that stage they might decide that it needs a fundamental rewrite. Of course they will not do this, but I suggest that they investigate the general level of the author's C++ expertise before they publish another book from him. You may wonder what we said about the first edition. Back in C Vu 5.5, the original more favourably impressed Chris Hills. I do not know if that is because it was less error prone or because Chris missed the technical problems. I have noticed that the more technically knowledgeable and experienced reviewers of Ira Pohl's books are, the more damning the review.