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++ in Plain English
Author:
Brian Overland
ISBN:
1 55828 472 9
Publisher:
MIS Press (Pitman)
Pages:
561pp
Price:
£18-99
Reviewer:
Francis Glassborow
Subject:
beginner's c++
Appeared in:
10-5
The main text ends on page 225 and the rest isC++ 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.