Long shrift: 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. Gergory 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:
manipulating amounts of money, dates, text fields, or any of the
other absolutely essential1
elementary data types in a
typical commercial application.
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.
Among the glut of C++ books
What's "Essential"?
So just what does Mr. Lippman view as "essential" for an
applications programmer just starting to learn C++?
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
the 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 ostream
parameter (p. 51) in a sort
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 Stack class
that
"supports the following interface: pop(),
push(), size(), empty(), full(), peek(), print()"
Clearly some of those methods (empty())
have empty parameter lists , while others
(push(item)) don't.
In the case of operator*()
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.
vector
with the same data (because STL vector
can't take an initialization list). The rest of the example could have used a built-in array just
as well as the STL vector.
enum
to 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 getline function.
One can be an authority on a programming language without knowing much about programming.3
Not recommended
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.