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

export

was introduced in the last two years. This author lists 49. As his list includes relatively new ones such as

namespace

and

typeid

and omits

asm

that 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

conditional

is used in the description of the keywords

if, for

, and

while

with an important technical meaning. The author correctly uses it in his formal description of

for

and

while

but not in

if

. I cannot imagine what source he was using that got

while

correct and not

if

.

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 namespace

declaration when he means a

using

directive. Unfortunately there is something called a

using

declaration but that is what he calls a

using

definition.

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

main

return an

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

return

statement is equivalent to returning zero.

He tediously introduces you to C's

printf

and

scanf

and 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:

CStr&CStr::operator=(const CStr&source){
cpy(source.get());
return *this;
}

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::cpy

and

CStr::get

. The implementation of

CStr::cpy

makes 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

CStr

.

These are just a few examples of why I would not recommend this book to my worst enemy let alone an innocent novice.