The main text ends on page 225 and the rest is C++ the Language, an Alphabetical Listing . That description must be taken loosely as it includes such things as 'Abstract Data Types' and 'Aggregates'. In other words terms that are not strictly part of C++ but which will frequently be used when writing about C++.
Let me tackle the reference part first. Getting reference material correct is not that difficult so it can act as a good indicator of the degree of research that an author has done in preparing a manuscript. So let me take a couple of examples that may help you judge the quality of this author's research.
Knowing which words are reserved and which words are keywords is pretty important particularly when not all compilers are completely up to date. There are 74 keywords in C++ and only
exportwas introduced in the last two years. This author lists 49. As his list includes relatively new ones such as
asmthat has been in the language for as long as most of us can remember I can only conclude that he simply listed the ones that he could remember.
When describing the formal grammar of C++ there are a number of specific terms that carry important meanings. For example
conditionalis used in the description of the keywords
if, for, and
whilewith an important technical meaning. The author correctly uses it in his formal description of
whilebut not in
if. I cannot imagine what source he was using that got
whilecorrect and not
Sometimes the problem is just that the author misuses a technical term with the result that readers will be confused when they meet them used correctly. For example the author talks about a
using namespacedeclaration when he means a
usingdirective. Unfortunately there is something called a
usingdeclaration but that is what he calls a
As a last example of the inadequacies of the reference section check out
identifiers. The author correctly specifies the permitted character set and warns about using leading underscores. But he never mentions that a double underscore is reserved to implementors for name- mangling algorithms. It is unlikely that you will ever fall foul of that but it is the kind of detail that should be in a reference section.
Let me now turn to the first part of the book. Quite apart from the fact that the author seems to be confused as to whether he is writing about C or C++ his knowledge of C++ seems weak. He asserts that C++ requires you to write void main(). Nothing could be further from the truth. C++ requires that
int. (I know that because I was the author of the technical paper that resulted in the C++ Standard making this an explicit rather than implicit requirement) It even provides special support to lazy and/or careless programmers by declaring that falling out of main (i.e. reaching the end of it) without a
returnstatement is equivalent to returning zero.
He tediously introduces you to C's
scanfand later tries to justify it on the grounds that using C's i/o mechanism or C++'s is a matter of personal taste. There are so many practical reasons to choose the C++ mechanism when writing C++ that it beggars belief that anyone could seriously wish to defend the C mechanism in a C++ context. Just let me give you two: the C++ mechanism is type- safe, the C++ mechanism can be extended to user-defined types.
One place that I regularly check in books for C++ novices is for any examples of overloading the assignment operator. Let me quote from page 163.
The assignment function turns out to be trivial to write once you understand all the syntax. Here's the shortest version of this function:
The function doesn't need to be any longer than this; it works perfectly well. In fact, this function is so short that it is a good candidate for function inlining.
The full horror of the above is only revealed when you start investigating the declarations and implementations of
CStr::get. The implementation of
CStr::cpymakes no attempt to determine whether the object being copied overlaps the place it is being copied to. Instead there is a check to see if the current length of the string is the same as the array of char being copied. Actually that will prevent the grossest forms of self copying but hang around a moment. What happens if the two arrays of char are different lengths? The memory for the internal representation is released by a conditional (if the pointer is not
NULL) call to
free(). Why not
delete(which subsumes the check for a null pointer)? Enough said. This implementation is written by a C programmer with only a superficial grasp of C++.
The prototype for
get(char * CStr::get();)reveals another horror, the implementation provides unrestricted access to the internal data of
These are just a few examples of why I would not recommend this book to my worst enemy let alone an innocent novice.