How should I review a large brick of a book that contains 1001 articles loosely grouped into forty-five sections, with items varying from half a dozen lines to several pages? I hope you do not expect me to read such a book from cover to cover. Actually I am not entirely clear as to how the author expects this book to be used. Some of the 'tips' are so basic that only the rawest novice would be interested while others would seem to be aimed at experienced developers.
The book covers both C++ as a language (though the author keeps injecting C, and something he calls C/C++ - OK I know what he means, but I still wish he would keep a clearer focus), specifics of Microsoft's implementation, MFC and MSWindows programming. Those latter parts reduce any possible value the book might have outside the MSVC++ market.
What I did for this review was to sample the book. If a book like this is to be useful then it should be generally correct rather than just good in parts, the target reader needs to trust it and will be unlikely to know good from bad. Let me relate a few of my experiences.
Tip 288, Determining When to Use Templates and Overloaded Functions consists of two paragraphs of text spanning nine lines. In that text there appears to be only one line related to the subject
If you must perform different operations for the various data types, you have to resort to function overloading.
I think even that simple sentence is not entirely true. It ignores issues of overloaded function templates and function template specialisations. So we have a complicated issue that the author, frankly, trivialises.
The very next tip exhibits another problem with this book. After a chatty introduction under the heading Understanding Pointers to Functions we come to a couple of pages of source code. The first block of code is a trivial example to communicate the syntax of declaring a function pointer. It is pure C and I have no quarrel with it. However the next part starts with
#include stdio.h
#include iostream.h
#include string.h
Why both C and a pre-standard C++ i/o? Actually he only uses the C++ i/o. A little later in that code he writes
#define COMMANDS (sizeof (Commands) / sizeof (char *))
why did he not write
int const number_of_commands = (sizeof(Commands)/sizeof(char*))
You may think this is a small issue, but it goes to show that the author does not instinctively write good C++ code when he uses C++. Though the purpose of the code is simply to illustrate using a table of function pointers driven by user input, he spends almost a page giving definitions of the seven functions he is using. This space could have been put to better use.
My next random selection took me to tip 474 Using the MFC CFont Class. This tip consists of two three-line paragraphs. The first is
The Microsoft Foundation Class library's CFont class encapsulates the HFONT object of the Graphics Device Interface and contains the functions for manipulating and using the font object. If you've mastered the HFONT object, you will have no problems with the CFont class.
No cross-reference is provided for HFONT so off to the index; nothing there under HFONT. Next I looked under Graphics Device Interface where I found two tips re fonts but still nothing on HFONT. 439, GDI Objects Fonts is three paragraphs, totalling fourteen lines. The first paragraph starts
A "font" is a lead or stone basin used to hold baptismal water,
However interesting the rest of this tip may be to the quiz contestant it adds nothing to our understanding of the GDI object.
The next tip, Understanding Font Families is not much better. It may be very interesting to learn that the term 'italic' should only be applied to serif fonts and that 'oblique' is the equivalent for sans-serif ones, but exactly what has that to do with Visual C++ Programming?
Tip 43, Understanding the Difference Between a Declaration and a Definition will help you place the level of the author's understanding of the technical language of programming. I will quote a single line
Defining an object or data type does not reserve any storage. That part of the operation is left to the declaration.
I think that suggests that the author has never bothered to read books written by good writers. If he had, he must be profoundly confused by their use of such terms as 'function declaration', 'forward declaration' etc. Perhaps that explains the general confused state of much of this book.
Next my eye fell on tip 111 Finishing the Program Editor
Before leaving the Visual C++ environment, you need to add some code to the ProgramEditor project you started at the beginning of the section. This code will turn the program into a usable, minimal editor for creating and editing source code for the examples I present throughout this book. ...
I was shocked. I thought (and the back cover supports that belief) that this was a reference book for those that were using Visual C++. Obviously both the publishers and I are mistaken. I leave you to add your own reactions to that, so revealing, paragraph.
I think I have written enough. Nothing will transmute this book from lead to gold. It is at best confused or irrelevant, and at worst it is plain wrong in ways that will make it harder for you to understand good books that are technically correct. I think I will wind packaging tape round my review copy (to ensure that it does not confuse any visitor that happens on it) and use it as a doorstop for which its solid bulk makes it admirably suited. And Addison-Wesley could do us all a favour by dropping its distribution of books from Jamsa Press, their production process is clearly inadequate (this is not the first of their books that have caused me great concern, largely for similar reasons).
