Path: utzoo!mnetor!uunet!husc6!cca!alex
From: alex@cca.CCA.COM (Alexis Layton)
Newsgroups: comp.lang.c++
Subject: Re: Readable C++ book
Message-ID: <26869@cca.CCA.COM>
Date: 11 Apr 88 21:30:43 GMT
References: <804@imsvax.UUCP> <6590028@hplsla.HP.COM>
Reply-To: alex@CCA.CCA.COM.UUCP (Alexis Layton)
Organization: Computer Corp. of America, Cambridge, MA
Lines: 113

Well, I don't know what book you were reading, but I found

	_An Introduction to Object-Oriented Programming and C++_
	(Richard S. Wiener & Lewis J. Pinson.  Addison-Wesley.
	ISBN 0-201-15413-7.)

very disappointing.  The authors appear to have experience with object-oriented
programming languages, but their hands-on knowledge of C++ is suspect.  I found
the book full of annoying little errors.  Many of the examples contain
minor C or C++ errors as well as non-idiomatic usage of the language.

For example, section 3.2 page 25, discussion of enumerated types is very
misleading in regards to what was possible in C and what is necessary
in C++.  They seem to insert ``typedef'' in structure and enum declarations
(almost at random).  Example:  Listing 3.2:

	#include <stream.h>

	typedef enum { red, green, amber} traffic_light_color;
	typedef struct intersection
	{
	  traffic_light_color traffic_light;
	  int number_cars_queued;
	  int cumulative_number_cars;
        };

	  // etc

[Any typos probably mine.]  By the way, they have this confusion about typedefs
and enums throughout the book.

I find their use of long class names in lower case (with underscores) hard
to read, although that is a less-important nit.  I would write the
preceeding as

	#include <stream.h>

	enum TrafficLightColor { Red, Green, Amber };
	struct Intersection {
	    TrafficLightColor traffic_light;
	    int               number_cars_queued;
	    int               cumulative_number_cars;
        };

which is a little easier to read, fonts aside.  The authors never use
capitalization for class names, which is the most common style.

Other places with problems:

Section 3.5 page 35, discussion of pointers:

	x = new float[ 1 ];
	y = new float[ 1 ];

Why would anybody in his or her right mind want to do this, rather than

	x = new float;
	y = new float;

?  The authors seem to be of the impression that new must always be of the
vector form.

Listing 4.12 page 76

	class outer_class
	{
	  private:
	    int y;
	    inner_class x;
	    inner_class r;
          public:
	    outer_class( int z );

	    void write() { printf( "\n%d", y ); }
	    void write_inner_x() { x.inner_class::write(); }
	    void write_inner_r() { r.inner_class::write(); }
        };

Now, I believe that the two write_inner_* methods are not well-formed C++,
and even if they were, what is wrong with x.write()?

Listing 4.18 pp. 87-88.  The use of simplify in class rational_number is
totally off-base.  It is a member function, declared as

	class rational_number
	{
	  // ...
	  private:
		void simplify( rational_number &num );
	  // ...
	};

but it is used and defined as if it were a normal function:

	simplify( *this );

This is ludicrous in the extreme.  Similar confusion about memberhood
abounds in the rational number example.
Look also at Listing 4.19 for the implementation of simplify.

I thought when I got this book that I finally had something I could give
to the many C programmers around here to introduce them to the language.
But the number of errors and misconceptions in the text make me hesitant
to use this book because I think it will just confuse people.  It is
vitally important in a teaching book that all the examples be not only
correct but also idiomatic.

Apologies to anyone who objects to the tone of this, well, flame.  I
guess I had my hopes up....


					Alexis Layton
					alex@CCA.CCA.COM