REVIEW - C++ in Plain English


Title:

C++ in Plain English

Author:

Brian R. Overland

ISBN:

Publisher:

Wiley (1996)

Pages:

561pp

Reviewer:

Francis Glassborow

Reviewed:

October 1998

Rating:

★☆☆☆☆


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.


Book cover image courtesy of Open Library.





Your Privacy

By clicking "Accept Non-Essential Cookies" you agree ACCU can store non-essential cookies on your device and disclose information in accordance with our Privacy Policy and Cookie Policy.

Current Setting: Non-Essential Cookies REJECTED


By clicking "Include Third Party Content" you agree ACCU can forward your IP address to third-party sites (such as YouTube) to enhance the information presented on this site, and that third-party sites may store cookies on your device.

Current Setting: Third Party Content EXCLUDED



Settings can be changed at any time from the Cookie Policy page.