[comp.lang.c++] disappointed with Pohl's C++ book

frew@hub.ucsb.edu (James Frew) (09/01/89)

I'm 1/3 of the way through "C++ for C Programmers", by Ira Pohl, and
I'm not going to finish it.  Herewith a summary of the problems I've
encountered so far:

p.	what
--	----
10      The example contains an expression of the form "int = int *
	double." This causes a warning message from CC (ATT 2.0).  The
	warning message is not mentioned in the text.

	This problem occurs in several subsequent examples.

16      CC gives a "used but not set" for class instances accessed only
	via their members.  The warning is not mentioned in the text.

16      The output given for the example program is obviously
	incorrect.

17      The use of the same name for a member function and a global
	function is given as an example of "overloading".  Is this
	true?  I sure can't find this in bs's book, and it's not
	analogous to structures, whose members have their own
	namespace.

35      Ever since reading Harbison & Steele, I've been conscious of
	the important distinction between declaration and definition.
	That distinction is muddied here in the section named
	"Declarations", and elsewhere in the text.

37	random() is NOT a "standard library function", it's a BSD-ism.

48-49   an example is given of a program printing out uninitialized
	"new" storage.  The comment in the "dissection" is "The
	programmer is responsible for properly initializing such
	objects".  Why not just leave it out of the example altogther?

51	An example of anonymous unions contains the following code:

		union {
			int	i;
			char	c[4];
		};

		main()
		{
			i = 65;
			cout << form("%c", c[3]) << "\n";
		}

	and it is asserted that the output is the letter "A".
	Obviously not tested on a VAX...  for that matter, obviously
	not tested at all, since CC won't compile it unless the union
	is explicitly static (g++ 1.35.0 won't compile it at all...)

70      A very confusing reference to the fact that structure member
	functions share the same name space as structure member
	variables.

71	A code fragment contains:

		char stack::pop(int n)
		{
			while (n--)
				top--;
			...
		}

	Is there some reason why the loop isn't just "top -= n" ?

71-72   An example contains a both a structure and a member named "s".
	The subsequent text refers to "the variable s": it's not clear
	which one.

By this point, I found myself spending more time looking for mistakes
than trying to understand C++.  I am especially disappointed in the
poor quality of the examples, since I believe the best way learn a new
programming language is to read real programs (and, of course, start
writing your own).  It takes special care to construct useful examples
out of a tutorial subset of a language, but it can be done -- witness
both editions of "The C Answer Book" by Tondo and Gimpel.  This care
simply wasn't taken in "C++ for C Programmers", and as far as I'm
concerned, that torpedos the whole book.  Remember, the intended
audience was people who already knew C, and therefore shouldn't be
afraid of reading non-trivial code.

Sorry to flame a book I'm not going to finish -- any counter-opinions?
I'm still looking for a good intro to C++ for someone who already knows
C.  Would anyone out there who's read Lippman's or Dewhurst's books
care to comment?

#-----------------+-----------------------+-----------------------------
# James Frew      | frew@crseo.ucsb.edu   | Computer Systems Lab., UCSB
# +1 805 961 8413 | frew@ucsbuxa (BITNET) | Santa Barbara, CA 93106, USA

lijewski@batcomputer.tn.cornell.edu (Mike Lijewski) (09/01/89)

I've never read Pohl's book so I can't comment on that.  Lippmann's
book is quite well done; definitely written for experienced programmers.
There are a few mistakes here and there, but all are minor typos.
The main problem with the book is that he tries to teach C at the same
time.  The end result is that we don't get into the meat of C++ until
almost halfway through the book.  The appendices on the iostream library,
the differences between C and C++, and the future directions for C++ are
well worth reading.

-- 
Mike Lijewski  (H)607/277-7623 (W)607/255-0539 (desk)607/255-2960
Cornell National Supercomputer Facility
ARPA: mjlx@cornellf.tn.cornell.edu  BITNET: mjlx@cornellf.bitnet
SMAIL:  1122 Ellis Hollow Rd. Ithaca, NY  14850

ray@saturn.ucsc.edu (Ray Swartz) (09/01/89)

I am currently reading Dewhurst and Stark's Programming in C++ book
and I can recommend it.  The book begins with a too short talk on C
(that I skipped) and then goes into C++.  It has the usual assortment
of obvious classes (Strings, Trees, etc) but what I particularly like about
the book is the insights contained in the text.

I find the hardest thing to learn about a language are the tidbits that
can save hours of confusion until the "Ahh-ha" occurs.  There are
several in there that were not obvious and that I am glad I read.

Ray Swartz

jonnyg@umd5.umd.edu (Jon Greenblatt) (09/01/89)

In article <2293@hub.UUCP> frew@hub.ucsb.edu (James Frew) writes:
>C.  Would anyone out there who's read Lippman's or Dewhurst's books
>care to comment?
>
>#-----------------+-----------------------+-----------------------------
># James Frew      | frew@crseo.ucsb.edu   | Computer Systems Lab., UCSB
># +1 805 961 8413 | frew@ucsbuxa (BITNET) | Santa Barbara, CA 93106, USA

	I have read the Programming in C++ book by Stephen Dewhurst and
Kathy T. Stark. Unfortionatly after completeting that book and a book on
C_Talk I had determined that I realy needed a language with a more dynamic
environment for my particular app so I had to scrap both. Although I never
got to program in C++ I did find the Dewhurst book fairly complete and too
the point. The book assumes you have a good working knowlege of C and
understatand OOPs to some degree. Although I did not try to compile and run
the examples in the book I did not notice any incongruities in them. The book
covers C++ V1.2 but only those features which will be found in V2.0. If someone
could document the differences between V1.2 and V2.0 it would help in
this case.

					JonnyG.

jima@hplsla.HP.COM (Jim Adcock) (09/02/89)

The consensus seems to be that Lippman is the first choice, with Dewhurst
being a good seond choice.  I think everyone is still waiting for a C++
book concentrating on good examples of OO programming.

[For the record: another new book out is Bruce Eckel: "Using C++".  I've read/
 scanned most of it, and am not impressed.]

nagle@well.UUCP (John Nagle) (09/04/89)

      Yet another error in Pohl's book is on page 88, where he says,
"A class with a static member cannot have a constructor."  This is
of course incorrect, and Pohl thus misses out on the whole area of 
classes which have internal relationships among their instances
maintained automatically by the constructors and destructors of the
class.  (See Stroustrup, 5.4.4).  

      The real restriction, according to Stroustrup, is that a static 
member of a class cannot be of a type which has a constructor.  Static
members are also forbidden initializers.  (At first thought this
seems strange.  After all, static members are really just global
variables to the implementation, and global variables can be of
a type with a constructor.  But think about what happens when a
class definition is included into several files.  Who does the
initialization?)

					John Nagle

diomidis@ecrcvax.UUCP (Diomidis Spinellis) (09/05/89)

In article <2293@hub.UUCP> frew@hub.ucsb.edu (James Frew) writes:
>I'm 1/3 of the way through "C++ for C Programmers", by Ira Pohl, and
>I'm not going to finish it.
[...]
>I'm still looking for a good intro to C++ for someone who already knows C.
I started reading the book:

@Book{	
	Author="Richard S. Wiener and Lewis J. Pinson",
	Publisher="Addison-Wesley",
	Title="An Introduction to Object-Oriented Programming and {C++}",
	Year="1988"
	ISBN="0-201-15413-7" 
}

I have already tried the Bjarne Stroustrup book and a tutorial on C++
by the same author published in the EUUG September 1985 proceedings.
I could not follow any of the two as they were trying to teach C and
C++ at the same time.  (The tutorial had just a faster pace).

The Wiener book is up to now (page 33) extremely readable (I found
myself reading it at breakfast) and assumes a good knowledge of C.  Its
pace is just right, concentrating on things new to a C programmer while
ignoring aspects of the C language a C programmer should be familiar
with.  This keeps the book interesting.

The chapters of the book are:
1. Object-Oriented Programming				(10 pages)
2. From C to Shining C++				(10 pages)
3. Getting Up to Speed with C++				(32 pages)
4. Data Encapsulation and Data Hiding Using Classes	(66 pages)
5. Inheritance and Derived Classes			(58 pages)
6. Polymorphism and Virtual Functions			(38 pages)
7. Case studies in Object-Oriented Programming		(87 pages)
 7.1 A "Super Fast" Spelling Checker
 7.2 Bank Teller Discrete Event Simulation
 7.3 Interactive Function Evaluator

I have no affiliation with any of the authors or the publishing company.

Diomidis
-- 
Diomidis Spinellis          European Computer-Industry Research Centre (ECRC)
Arabellastrasse 17, D-8000 Muenchen 81, West Germany        +49 (89) 92699199
USA: diomidis%ecrcvax.uucp@pyramid.pyramid.com   ...!pyramid!ecrcvax!diomidis
Europe: diomidis@ecrcvax.uucp                      ...!unido!ecrcvax!diomidis

jima@hplsla.HP.COM (Jim Adcock) (09/06/89)

// >      The real restriction, according to Stroustrup, is that a static 
// >member of a class cannot be of a type which has a constructor.  Static
// >members are also forbidden initializers.  (At first thought this
// >seems strange.  After all, static members are really just global
// >variables to the implementation, and global variables can be of
// >a type with a constructor.  But think about what happens when a
// >class definition is included into several files.  Who does the
// >initialization?)

//--------------------------------------------------------------------

// Consider simulating the effect of static members with init'ers 
// by using references:

#include <stdio.h>

class withIniter
{
  const char* stringp;
public:
  withIniter(const char* p) { stringp = p; }
  void print() { printf("%s\n", stringp); }
};

withIniter withStaticMember__classname("withStaticMember");

class withStaticMember
{
  withIniter& classname;
  int someMembers;
public:
  withStaticMember() : classname(withStaticMember__classname) {}
  void printClassname() { printf("class name is: "); classname.print(); }
};

void main()
{
  withStaticMember someObject;
  someObject.printClassname();
}

// Compiles and executes as expected under 2.0.  Class definitions included in 
// several files is not an issue here [or maybe it is :-] since 
// withStaticMemberClassname must be defined once, in a file of your 
// choosing.  Presumably the "right" place to define withStaticMemberClassname 
// would be in the file defining the member functions of withStaticMember -- 
// IE withStaticMember.c -- assuming one is following the generally sensibly 
// approach of creating a library of seperately compiled classes.
// Still, these problems show that following the .c & .h approach of c
// is really just a hack in order to maintain backwards compatibility with
// archaic compilers and linkers.  Ideally declarations and definitions --
// .h and .c information -- could be contained in one source file, and be 
// compiled into one library file.  Then the inline issues: where an inline
// gets declared, and whether a compiler can successfully inline it or not,
// would also go away.

jima@hplsla.HP.COM (Jim Adcock) (09/09/89)

//>      The real restriction, according to Stroustrup, is that a static 
//>member of a class cannot be of a type which has a constructor.  Static
//>members are also forbidden initializers.  (At first thought this
//>seems strange.  After all, static members are really just global
//>variables to the implementation, and global variables can be of
//>a type with a constructor.  But think about what happens when a
//>class definition is included into several files.  Who does the
//>initialization?)
//>
//>					John Nagle

//------------------------------------------------

// Oops -- I just noticed in AT&T's 2.0 release notes pg 4-12 that static
// members of a class can now have constructors, and can be initialized.
// There are new syntaxes for doing so.  I haven't seen this info elsewhere:

#include <stdio.h>

class withConstructor
{
  static withConstructor classname;
  const char* stringp;
public:
  withConstructor(const char* p) { stringp = p; }
  void print() { printf("%s\n", stringp); }
  void printClassname() { printf("class name: "); classname.print();}
};

withConstructor withConstructor::classname("withConstructor");

class withStaticMember
{
  static withConstructor classname;
  int someMembers;
public:
  withStaticMember() : someMembers(1234) {}
  void printClassname() { printf("class name is: "); classname.print(); }
};

withConstructor withStaticMember::classname = "withStaticMember";

void main()
{
  withStaticMember someObject;
  someObject.printClassname();

  withConstructor anotherObject = "something";
  anotherObject.printClassname();
}