ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Google+ ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

Search in Book Reviews

The ACCU passes on review copies of computer books to its members for them to review. The result is a large, high quality collection of book reviews by programmers, for programmers. Currently there are 1918 reviews in the database and more every month.
Search is a simple string search in either book title or book author. The full text search is a search of the text of the review.
    View all alphabetically
Title:
C++ How to Program
Author:
Deitel&Deitel, 3rd Ed.
ISBN:
0 13 089571 7
Publisher:
Prentice Hall
Pages:
unknown
Price:
$81.60
Reviewer:
Gregory Haley
Subject:
beginner's c++
Appeared in:
14-1
What strikes me most about this book is that, in contrast to many other texts revised or written after the release of the latest standard, Deitel and Deitel appear to have made no effort to update their material to reflect the new standard. Beyond this failing, I was more struck by a number of inconsistencies in their approach to teaching C++ that are in defiance of widely accepted standards and idioms and are downright dangerous. Perhaps in a classroom setting, the errors of logic can be explained, and the student will still benefit from the reading. Two examples:

Deitel and Deitel are the only authors of any programming language I have read who argue against using zero based for loops, of the form:

for(i = 0; i != boundary; ++i)
. Rather, their written preference is for the form:
for(i = 1; i = boundary; i++)
. Throughout the book, however, when convenient, they will use the zero based form, then switch, sometimes within the same program, to a one-based form. What is the student to make of the inconsistency?

The authors, to their credit, argue against the use of magic numbers when coding, and they quite correctly point out that tracking down and changing all the magic numbers in a program is both tedious and error prone. Again, they cannot practice what they preach. Over and over, they publish code samples that are full of magic numbers. This is simply sloppy work. What is the lesson the student is supposed to take away from this sort of teaching?

There are numerous examples of unworkable code that has been copied line by line from the second edition of the book (and maybe even the first). This is code that will not run on all platforms. The authors either did not bother to correct their errors, or they simply did not care. Worse, the creation of platform dependent code flies in the face of the C++ goal of platform independence.

Any pedagogy should be founded on the principle of "best practices". Sloppy habits are all too easily acquired, and even more painful to correct. In numerous instances, the authors have published code within the body of the text which they will admit does not reflect the "most efficient" approach, and they leave it to the student to discover the more efficient approach as an exercise. This does the student a grave disservice. Teach most efficient method and save the flawed implementation as an exercise to reinforce the real lesson.

The pursuit of inconsistent and unworkable code, the promotion of coding practices that really do fly in the face of common practice, and the inattention to detail are sufficient to give this book a "Not Recommended" rating. What really clinches it, however, is that there is so little evidence that the authors have followed the developments of the standard and the many advances, particularly in the area of memory management. The chapter on strings never mentions the vector class. The chapter on classes introduces the first class without providing for a destructor. This is beyond not keeping up with developments in the language. I finally stopped reading at this point: such an omission marked the book as fatal.

Whereas the ideal approach would introduce the standard libraries and the STL early and often and use these to demonstrate their advantages, the authors build a foundation without these very valuable, no, important, "flying buttresses". Rather they save any coverage of the STL for a chapter tagged on to the end of the book. As with their use of flawed algorithms, they leave it for the student to work out for himself or herself how to incorporate this new material into the nearly 900 pages of material that preceded it.

Do not buy this book, and if someone tries to give you a copy decline, politely, then firmly. You will learn here not so much what to do, as you will learn practices that you will spend double the time learning to undo.Java