REVIEW - Object-Oriented Programming in C++


Title:

Object-Oriented Programming in C++

Author:

Robert W. Lafore, Waite Group

ISBN:

Publisher:

Sams Publishing (2002)

Pages:

1012pp

Reviewer:

Francis Glassborow

Reviewed:

April 2002

Rating:

★★☆☆☆


The author states that this book requires no previous programming knowledge. I do not dispute that, but I do question the validity of covering things like casts and manipulators in the second chapter (C++ Programming Basics). In my experience newcomers can easily get swamped by excessive detail. There is also the problem of the author's lack of precision that surfaces in this chapter. For example on page 36 he is explaining the purpose of a using directive (by the way, he never seems to explain the far more useful 'using declaration') and he writes:

... 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.


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.