Search in Book Reviews

There is a profound irony in the title of this book because judging by the review of the author's second edition of Practical C++ you might think this title was appropriate to that book. Indeed readers of that book will find much in this book will illuminate some of the bad experiences they have had as a consequence of reading it.

This book is orders of magnitude better in both design and concept to the other books from the author. Perhaps this is because what is a vice elsewhere is a virtue here. The substance of the book is 114 short programs of which all but 3 are in the opinion of the author, profoundly broken even if they compile and execute.

Now I am not sure to what extent pure C programs have their place in this book, and I am not sure that a program that outputs an octal result when a decimal one was intended should actually be described as broken but let me leave that aside. What I like about the book is that it makes the reader think and has been designed to avoid accidentally seeing an answer. At the end of each program the author provides a hint number and a an answer number. Neither the hints nor the answers are in the same sequence as the problems. Some hints provide references to further hints (there are a total of 361 hints). But he also provides 115 answers. As far as I can see no problem is supplied with two answers so which answer does not have a problem? Then there is the matter of the chapter with the three working programs. Well problem 103 isn't a program, problem 104 needs the ability to read minds and problem 105 would be better in an obfuscated C contest.

There are numerous other problems with the author's solutions. For example one problem assumes that MSDOS based compilers always used 16-bit

int

s. While most did that is not true in all cases and how would a modern programmer spot that? Of course the problem could have been rephrased so that it was stripped of OS specific references.

Now, despite my carping I like the concept of this book and the execution of the concept is not bad either though it could have done with a thorough technical review to ensure that problems were set carefully and that answers were free of subsequent errors. I think that some of the problems should simply have been thrown out (problem 5 is certainly not a broken program and would output exactly what you might have expected in some environments (some systems would add a carriage return as part of the exit procedure from a program. If you do not suffer from high blood pressure and do not mind some problems being defective this book could while away the odd hour. The sad thing is that if the author had ensured that all the broken programs were actually broken the challenge would have been greater. Instead I have a continual doubt that the problem program I am looking at is in fact broken and that spoils the challenge.