REVIEW - How Not to Program in C++ - 111 Broken Programs and 3 Working Ones, Or why Does 2+2


Title:

How Not to Program in C++

111 Broken Programs and 3 Working Ones, Or why Does 2+2

Author:

Steve Oualline

ISBN:

Publisher:

No Starch Press (2003)

Pages:

280pp

Reviewer:

Francis Glassborow

Reviewed:

August 2003

Rating:

★★☆☆☆


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.


Book cover image courtesy of Open Library.





Your Privacy

By clicking "Accept Non-Essential Cookies" you agree ACCU can store non-essential cookies on your device and disclose information in accordance with our Privacy Policy and Cookie Policy.

Current Setting: Non-Essential Cookies REJECTED


By clicking "Include Third Party Content" you agree ACCU can forward your IP address to third-party sites (such as YouTube) to enhance the information presented on this site, and that third-party sites may store cookies on your device.

Current Setting: Third Party Content EXCLUDED



Settings can be changed at any time from the Cookie Policy page.