REVIEW - C++ In Plain English


C++ In Plain English


Brian Overland



Wiley (2000)




Francis Glassborow


June 2001



Let me start with the short version of this review. Despite the number of pages and the relatively low cost, leave this book on the bookshop's shelves. In simple terms it is too far behind current C++ good practise to be worth consideration. If you want to know why I feel this way, read on.

The book comes in two parts. The first part is a reference, the second purports to be a tutorial. Let me be honest, I do not read reference books, I test them by trying a few things.

I am always interested in how much use an author is making of the full Standard C++ Library. I started by looking up string, it was not there however I did find a whole bunch of purely C library functions. Looking further I discovered that the author never covers string or wstring anywhere in this book. I will have a little more to say on this point when I cover the tutorial section.

Next I took a look at dynamic allocation of memory. The author tells me that if I want to do this I should look up new and malloc. Curious because they do very different things. What I found was less than helpful, he mentions both new and new[] but does not seem very clear in his mind about the dangers of confusing them when using delete and delete[] (he just says that you should avoid mixing them, nothing about this being a serious error). He has nothing to say on the subject of the placement new syntax (important because less expert C++ programmers often get in a mess by adding parentheses where there should be none.) Much more to the point, when I looked up operator new in the index, I was directedtowards a table that then referenced the brief entry for what knowledgeable C++ programmers know to be the new expression. Details like this need to be correct because the language is confusing enough already. Of course operator new is the C++ replacement for malloc.

As I continued my exploration it became clear that this book is written about a version of C++ that ceased to exist before the date of publication of the first edition of this book. This edition is copyrighted 2001 and that makes the author's assertions that such things as mutable are not supported by some C++ compilers revealing as to how recently he looked. I am not silly enough to claim that all compilers support mutable, but you have no reason to be learning with one that does not.

As I was flicking through the pages I noticed an entry for gets(). Now this is a C function that even C programmers mark as conceptually broken. However the author gives no real indication of this, just tells the reader to ensure that they use a big enough buffer. I also noticed that the author covers the additions to the Standard C Library that were made in 1995 to support wide character processing. To the best of my knowledge these are not actually part of C++, though it would seem relatively harmless to include them if the author had also include such things as the spelt out operators (bit_and, xor etc.) and wcout etc. This led me to look at his chapter on iostream. That finally nailed his coffin; this chapter is entirely about the pre-standard iostreams and has nothing to do with the version in the Standard.

If you think I am being harsh, note that this book's copyright is three years after the C++ Standard was accepted by the National Standard Bodies of the world. I could list many more problems with the reference section, but I do not think I can justify the time and space. Furthermore the author has a major job on hand if he wishes to bring this book anywhere near a level of accuracy and completeness that this reviewer would find acceptable.

Now let me look briefly at the tutorial section. I wish that I could say that this redeems the book but it does not. The author's understanding of C is completely wrong. Yes, I know this book purports to be about C++, but often he uses C-style code but then reveals he does not understand it. Let me give a single example (I can assure the reader that this is one of many, I just have neither the time nor the inclination to waste my space with and extended list), on page 358 the author writes about string literals, here is a short quote

In the following example, "Hello" is a string literal.
char s[] = "Hello";

When you place a quoted string in a program, C/C++ does two things (a) it stores the character data in program memory; and (b) it passes along the string's address. Therefore, the effect of the preceding code is
char s[] = address-of-"Hello"

He very clearly does not understand the difference between an array and a pointer. Unfortunately, he does not understand how to write C++ either, nor does he have any appreciation of how modern C++ makes life simpler for less experienced programmers.

This is a bad book, written by an author who seems to have made only a superficial effort to follow C++ development. Before writing any more books about C++ the author needs to go back and learn C++ right from the start. I will leave you with one piece of code (from page 395) where the author is implementing a member function to copy an array of char into his seriously broken string class that he calls CStr. (nLength and pData are data members of CStr)

void Cstrcpy(char *s) {  // Copy string argument  	int n;  	n = strlen(s);  	if (nLength !=n) {  		if (pData)  			delete[] pData;  		pData = new char[n+1];  		nLength = n;  	}  	strcpy(pData, s);  }

So leaving aside the minor issue of why he did not initialise n in the definition, how do you copy an array of const char? What happens when s points to the same place as pData (effectively self copying)? Why bother to check for a null pointer (the delete expressions do that for you? I suppose it is too much to hope that the author might give any consideration to new[] failing. I do not care whether he knows about exceptions at this point, just that he might learn to write good idiomatic C++. In other words, some evidence that he has actually studied C++ from a good source.

Book cover image courtesy of Open Library.

Your Privacy

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

By clicking "Share IP Address" you agree ACCU can forward your IP address to third-party sites to enhance the information presented on the site, and that these sites may store cookies on your device.