Stanley Lippman: Essential C++ , 2000, Addison-Wesley, ISBN 0-201-48518-4, 270 pages.
We're giving this one more space than usual for a negative review. A new book from a well-known author and a respected publisher shouldn't be dismissed without a careful analysis and complete explanation.
I'm often asked to recommend the best C++ book for a course text or for self-study. That's a tough call. There are dozens, if not hundreds, of them, far too many to get acquainted with.
In the future, however, I'll have no trouble coming up with the worst C++ book I've seen. If there's a worse one out there than Essential C++ I hope I never encounter it. Stanley Lippman confronts his readers with a stream of silly examples, grotesquely misguided coding techniques, opaque writing, and just plain errors. This book has no redeeming qualities and is appropriate for no audience.
C++ with its standard libraries and vendor libraries is by far the largest language in the history of programming, vastly more complicated than PL/I, Ada, or Algol-68 which used to get criticized for being too big. Tackling a well-chosen subset, therefore, is an appropriate pedagogical approach. Gregory Satir's 198-page C++: the Core Language is more readable and far more sensible than Mr. Lippman's new book.
In reviewing the same author's C++ Primer I observed that it's anything but a primer. The scope of Essential C++ is anything but essential from the point of view of an applications programmer. Addison-Wesley needs help in choosing titles for Mr. Lippman's books.
A business applications programmer will find not a word in Essential C++ about how to define or use classes for:
It's as if a C++ compiler is an interesting plaything rather than a tool for serious software development.
The second chapter introduces (p. 42) a simple selection sort routine and then develops several versions of it. Mr. Lippman misidentifies it each time as "bubble sort"!
The bubble sort algorithm is well known, but this isn't it. Addison-Wesley editors, if they still have any, should have caught that, since they publish books that get it right (e.g. Robert Sedgewick: Algorithms, ISBN 0-201-06673-4). That terminology is long-established2 and not subject to new coinage.
An extra iteration in the outer loop doesn't affect the result, but may
momentarily confuse the reader who just learned a few pages earlier how
for statement works.
Whether to leave temporary debugging output statements in a program is
open to debate, but when we do so we normally turn it on or off by a
switch (internal, macro, global) unknown to the calling routine.
Providing an optional
parameter (p. 51) in a
routine (to route debugging output to a file of the calling program's
choice) is way too bizarre; an undergraduate student who did that on an
exercise would earn a stern comment from the instructor and at most a
grade of C.
Mr. Lippman appends an empty parameter list to the name of every function
regardless of the function's parameter-list signature. In fact he calls
foo()" (p. 35) a
function name. This odd convention, which serves no apparent
purpose, persists thoughout the text and the exercises.
That gets awfully confusing, for example when exercise 5.1 advises the
student to build a
"supports the following interface:Clearly some of those methods (
pop(), push(), size(), empty(), full(), peek(), print()"
empty()) have empty parameter lists , while others (
In the case of
the convention is completely ambiguous, offering no clue as to whether
the multiplication or the dereferencing operator was intended.
Whatever we may think of the writing, the structure, and the accuracy this text is riddled with examples of bad programming practice, ranging from mildly regrettable to grotesquely misguided. I'll just list them in no particular order of importance:
Implement a two-level stack hierarchy. The base class is a pure abstract Stack class . . . The derived classes are LIFO_Stack [What other kind is there?] and Peekback_Stack. The Peekback_Stack allows the user to retrieve the value of any element in the stack without modifying the stack itself.The sample solution presents vast duplication of code in the two derived classes. Exercise 5.2 presents a reasonable correction.
vectorwith the same data (because STL
vectorcan't take an initialization list). The rest of the example could have used a built-in array just as well as the STL
enumto give a symbolic name to each of the subscripts even though the original function names are known at this point.
if (condition) option = true; else option = false;which we hope students will understand is equivalent to and should be written simply:
option = condition;
>>) overloaded for the standard (
string) class (p. 206) to obtain the user's name from the console keyboard is fragile and user-unfriendly. (It quits on an embedded blank!) The accepted practice is to use the
One can be an authority on a programming language without knowing much about programming.3
2 Other sources for the bubble-sort algorithm include:
3 This observation is often made these days about insiders in the "Java community". The phenomenon is certainly growing with the emergence of each new technology.
Return to book reviews.
Return to IDI home page.