Advertisement
Membership
Login
ACCU Buttons
Search in Book Reviews
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.
... The directive
using namespace std;
says that all the program statements that follow are within the std namespace.
It isn't so much that a novice will care about the accuracy of this statement but that the author could write it and his technical reviewers could let it pass without insisting on rephrasing such as 'brings all the names from namespace std into the current file so they do not have to be qualified for use. That would fit quite happily with the example that follows (of using std::cout as cout).
A bit latter (page 54) we come across:
The declarations for the manipulators (except endl) are not in the usual IOSTREAM header file, but in a separate header file called IOMANIP.
Of course this is wrong. I/O manipulators that are stateless (do not have arguments) are all in iostream but those that require arguments are found in iomanip. By the way, though there is nothing wrong with spelling those header names in upper case it seems silly to do so when the book always uses lower case for them in source code. And if we are being pedantic, they are headers, not header files (there is no requirement that they physically exist as files).
Now let me move on to chapter 6 where the author tackles classes. The first thing that struck me is that the author never describes the default constructor nor mentions that it is compiler generated. Later when writing about the copy constructor he follows a common misuse of terminology by referring to a default copy constructor when he should be calling it a compiler generated copy constructor. On page 218 he explains private and public and on page 220 emphasises that data is private. He does not introduce protected until page 377, which means that the novice reader must be puzzled as hell by its use on page 225 in the definition of a circle class. Much worse from this reviewer's perspective is that this class definition lacks any private interface and throws all the data into a protected one. Again this is simply lack of attention to detail, well apart from the fact that I suspect he cut this code out of an inheritance hierarchy, but that is just my deduction.
I then tried to find out how the author presented copy construction and copy assignment in the cases where such things matter. I was shocked. I could find no coherent explanation of this process. His basic example code was for a class where it was not necessary. He made no attempt to even mention self-copying, nor is his code exception safe. He follows his simplistic introduction of copying with his version of a string class (I have no problem with his doing that even though C++ already provides it, it can make a good example). The first problem is that he complicates this by making it a reference counted implementation and uses raw pointers (no exception safety). My second problem is that the source code is very poor. Let me give you an example (psc is a pointer to a counted implementation):
String::~String() {
if(psc-count==1)
delete psc;
else
(psc-count);
}
Which seems an unnecessarily long-winded version of:
String::~String() {
if((psc-count) == 0) delete psc;
}
Note that we are halfway through the book by now so a more compact coding style seems appropriate. Actually I would write:
String::~String(){if(!(psc-count)) delete psc;}
but maybe that is a little terse.
He has mentioned both const member functions and constructor initialiser lists, so why does this example avoid both (the psc variable is initialised in the body of the constructors, and the display() function is not const qualified.
I think that is enough. This is not a bad book, though I would introduce C++ somewhat differently. However considering this is a fourth edition its lack of correctness is quite unacceptable. The publisher should require the author to get the book properly technically reviewed and have the numerous technical errors corrected. The source code should be brought up to a good standard so that readers will have code worth emulating and the general approach should be revised because while it is true that C++ has changed little since the last edition was produced, the way that C++ is used has changed extensively. These days we make increasing use of the STL and generic programming and we also concern ourselves with such things as exception safety.
I cannot recommend this book as it is, and every sale it makes will deter the author from putting in the effort to write the good book of which he is capable.