horstman@sjsumcs.sjsu.edu (Cay Horstmann) (05/02/90)
In article <6170017@hpindda.HP.COM> hardin@hpindda.HP.COM (John Hardin) writes: >> Do not buy 'Ira Pohl's` Book. >> >> -- >> Bharat >> ---------- > >I beg to differ. Would you mind posting some reasons for this opinion? >I found Ira Pohl's book to be an excellent introduction to the language. >It's short, to the point, and clearly written. Anyone trying to learn >C++ who finds themselves confused by the the book(s) they have would be >well advised to go out and pick up a copy of Pohl's book. > Can't disagree with that. The book has so little information that it can hardly confuse anyone. There really is very little there. Look at the "stock broker" example in chapter 1. It is hard to conceive of a more pitiful example for derived classes or virtual functions. Look at the aptly named "BStree." Or look at the incredibly dumb discussion of assignment to this. Either do it right or don't do it. (There is a lot to be said for the latter approach, with version 2, of course.) The book introduces the MECHANICS of SOME constructs of C++. I found it disappointingly short on IDEAS. Disclaimer: I am writing a C++ text myself, soon to be published by Wiley. So it is in my interest to say terrible things about other C++ books. Here goes: Pohl's book is bad. ALL other C++ books are bad. BUY MINE! :-> Seriously, I would recommend Lippman's book. It is a much better reference than Pohl's. For an intuitive introduction, I like Eckel's book. It has some nice sections (e.g. when to use references) that ease the transition C->C++. Cay
hardin@hpindda.HP.COM (John Hardin) (05/03/90)
Though I don't want to get into an extended argument over Pohl's book, I'd like to respond briefly to some comments made by Cay Horstmann for the possible benefit of someone looking for an introductory text. In reference to Pohl's book, Cay writes: > There really is very little there. Look at the "stock broker" example > in chapter 1. It is hard to conceive of a more pitiful example for > derived classes or virtual functions. Look at the aptly named "BStree." > Or look at the incredibly dumb discussion of assignment to this. Either > do it right or don't do it. (There is a lot to be said for the latter > approach, with version 2, of course.) Rather than being robust examples of C++ classes, Pohl's examples do little more than illustrate the specific point(s) being made. This often greatly enhances the clarity of the book. > The book introduces the MECHANICS of SOME constructs of C++. I found it > disappointingly short on IDEAS. When I bought Pohl's book I was looking for a clear tutorial on the mechanics of this new language rather than a complete reference manual. After reading it, I was so pleased with it that I bought a second copy for a colleague. > Disclaimer: I am writing a C++ text myself, soon to be published by Wiley. > So it is in my interest to say terrible things about other C++ books. > Here goes: Pohl's book is bad. ALL other C++ books are bad. BUY MINE! :-> I look forward to seeing it. Always room for improvement (at least until your book comes out :-) ). > Seriously, I would recommend Lippman's book. It is a much better reference > than Pohl's. For an intuitive introduction, I like Eckel's book. It has > some nice sections (e.g. when to use references) that ease the transition > C->C++. Lippman's book is indeed a better reference than Pohl's, but I found Pohl's to be a better first introduction to the language (personal opinion only). I'm quite happy that I have both. Considering the different needs of different readers and the fact that I found Pohl's book to be just what I needed at the time, I think it's not the best of advice to warn others away from it. John Hardin hardin@hpindgh.hp.com ----------
briand@infmx.UUCP (brian donat) (05/03/90)
In article <6170019@hpindda.HP.COM>, hardin@hpindda.HP.COM (John Hardin) writes: > Though I don't want to get into an extended argument over Pohl's book, > I'd like to respond briefly to some comments made by Cay Horstmann > for the possible benefit of someone looking for an introductory text. > Having just dealt with the 'first' obstacle of finding an introductory text on C++, I figure, that my opinion is of some merit with regard to this thread. I originally purchased -Dewhurst S.C. and K.T. Stark, "Programming in C++", Prentice Hall, Englewood Cliffs NJ, 1989 I'd gotten into about the third chapter in this book and found myself drowning. This is an excellent example of a book written by a couple of people who seem to have no empathy for the person who has never seen C++ before. Their knowledge of the language is readily apparent, I suppose, by the examples and descriptive text, but I, the beginner, had a hard time piecing things together because 'preliminary' building blocks on the concepts (and REASONING for them) was not provided in a SANE manner. So, I decided I needed to do some background research, to catch up on what the authors were dumping out in the few chapters I'd read. I purchased -Meyer B. "Object-oriented Software Construction", Prentice Hall (UK) Ltd, Hertfordshire UK, 1988 -Weiskamp K. and B. Flamig, "The Complete C++ Primer", Academic Press Inc, San Diego CA, 1990 I purchased Meyer's book because I was looking for something to help me get over the hurdle of understanding 'OOP'. Admittedly, the book is excellent for present OOP theory. It is however written in that highly academic and erudite style which can be very blase' reading. But none-the-less, Meyer does present some very interesting background with regard to the reasoning and evolution of OOP and its subsequent languages, particularly emphasizing the issues of 'software maintenance' and 'reusibility of code'. I learned a lot from the first part of this book and haven't finished reading it yet in totoal. The 'Eifel' language Meyer uses, at first gave me shudders, causing me to think, Oh no, the guy's trying to push his language off on me! , but instead, it serves as a good comparative example against features implemented in C++. For Example, Meyer mentions 'genericity'. You don't find this term in C++ texts, but you see it, I believe as the implementation of what C++ calls 'parameterized types' using macros. I'm glad I bought the Meyer book in this regard. I had some fundamental understanding provided from it, which later set the scene for my ventures into C++. The Weiskamp/Flamig book on the otherhand was in my opinion excellent. I can highly recommend it to the person who is just starting in C++, even if they don't go read something theoretical on OOP. The book is written in a clear and lively style which is easy to read, without getting insulting like some of those 'Waite' primers do. One 'Waite' book I once read contained statements in text from the author which seem to imply that I, the reader, was no more than a 17-year-old in highschool needing great amounts of hand-holding and some fatherly slaps on the hand for screwing up. By contrast, the only things that bothered me about the Weiskamp/Flamig book were the fact that it is rather voluminous, but this owes to a style, where the authors presented fundamentals first and then reviewed and built on them in each succeeding chapter; This approach seems to be a planned thing, and in no way does it make me feel like I'm the stupid 'nink' (that's short for nincompoop) who doesn't know anything about what the authors are trying to say. Matter of factly, they assume you already are very proficient in 'C' and can hack some rough water, if presented logically. The other bother about their book is that there are ideed many little 'typos' in the text (rather amusing actually). The Weiskamp/Flamig book left me with a well rounded grip on C++. It explained most everything, while stating differences between V.1.2 and V.2.0 (There's also an appendice detailing V.2.0 specifics and particularly, C++ vs. C differences. The authors make generous use of what they call 'Tranlation Boxes' which show what a C++ to C translator generates in 'C' code. With these translation boxes, they provide good solid explanations of how the C++ language achieves the OOP functionality which a C++ programmer finds so to his liking. The authors explain some of the rough issues of the language as well, eg. the notion that assignment of classes leads to a lot of data copying, etc.. They mention techniques used, such as 'reference counting', but don't go into detail. I was shocked to go back to the Dewhurst/Stark book and realize that they had just dumped me right into reference counting w/o any explanation, as early as chapter 3!!!! Being politely advised about such things is much to my liking, and the references to such things provided, actually perks my interest more and points me in directions whereby I may expand my knowledge of the language. You get the idea, though. Some authors have carefully considered and empathized with the needs of their audience and some, have just done a data-dump of what they know w. explanations and examples. I'm reading the Dewhurst/Stark book as a follow-on to the Weiskamp/Flamig book. I suspect I'll see other good examples of 'technique' in there, beyond the definition of the actual language. Anyway the Weiskamp/Flamig book is very very good. I highly recommend it. And then, I recommend such other texts as the Dewhurst/Stark for supplemental reading afterwards. And that's the experience of one person who has recently learned both OOP and C++. --briand --briand
reggie@dinsdale.paradyne.com (George W. Leach) (05/09/90)
In article <4143@infmx.UUCP> briand@infmx.UUCP (brian donat) writes: >Having just dealt with the 'first' obstacle of finding an introductory >text on C++, I figure, that my opinion is of some merit with regard to >this thread. >I originally purchased > -Dewhurst S.C. and K.T. Stark, "Programming in C++", Prentice Hall, > Englewood Cliffs NJ, 1989 >I'd gotten into about the third chapter in this book and found myself >drowning. This is an excellent example of a book written by a couple >of people who seem to have no empathy for the person who has never seen >C++ before. Their knowledge of the language is readily apparent, I >suppose, by the examples and descriptive text, but I, the beginner, >had a hard time piecing things together because 'preliminary' building >blocks on the concepts (and REASONING for them) was not provided in >a SANE manner. Did you read the Preface and Introduction? This book does not claim to be a primer. Nor does it claim to exhaustively discuss the features of the language. It does claim to show how to use the features. As such it it probably best to first use something like Stan Lippman's "C Primer" and then follow up with this book. But I feel that you can learn the language from this book as well. Different people need different approaches. >So, I decided I needed to do some background research, to catch up on >what the authors were dumping out in the few chapters I'd read. >I purchased > -Meyer B. "Object-oriented Software Construction", > Prentice Hall (UK) Ltd, Hertfordshire UK, 1988 > -Weiskamp K. and B. Flamig, "The Complete C++ Primer", > Academic Press Inc, San Diego CA, 1990 [Experiences regarding Meyer's book deleted] It should be noted that the progression from procedural programming to data abstraction to object-oriented programming presented in Dewhurst and Stark is quite clear and the right way to go for C++. In Weiskamp and Flamig they immediately dump you into OOP with only a page or so on data abstraction. They mix up terminology from Smalltalk and C++ and for good measure they create terminology all of their own. For the poor person just getting into this they will be speaking in tongues concerning the subject. >The Weiskamp/Flamig book on the otherhand was in my opinion >excellent. In my opinion, it is not! >I can highly recommend it to the person who is just >starting in C++, even if they don't go read something theoretical >on OOP. The book is written in a clear and lively style which >is easy to read, without getting insulting like some of those >'Waite' primers do. One 'Waite' book I once read contained >statements in text from the author which seem to imply that I, >the reader, was no more than a 17-year-old in highschool needing >great amounts of hand-holding and some fatherly slaps on the hand >for screwing up. Funny, that is pretty much how I felt about this book. The tone of the book is highly informal and the attempts at being humorous are out of place. The programming examples are so contrived and at times they try to be too cute with them. In a nutshell, I don't consider it a very professional treatment. >By contrast, the only things that bothered me >about the Weiskamp/Flamig book were the fact that it is rather >voluminous, but this owes to a style, where the authors presented >fundamentals first and then reviewed and built on them in each >succeeding chapter; This approach seems to be a planned thing, >and in no way does it make me feel like I'm the stupid 'nink' >(that's short for nincompoop) who doesn't know anything about >what the authors are trying to say. The size of the book is due to (1) lots of diagrams and pictures, (2) lengthy programming examples at times, and (3) large font. It is not due to content as is the case with Lippman's book. >Matter of factly, they >assume you already are very proficient in 'C' and can hack >some rough water, if presented logically. The other bother >about their book is that there are ideed many little 'typos' in >the text (rather amusing actually). Not amusing to me. If someone pays for a book they should receive a polished product, not something that looks like it didn't get enough time in the review cycle. One typo happens to be in a very significant place,in an example (pg. 126) where the concept of virtual functions is introduced. A class is presented, followed by a derived class, however, the derived class does not refer to the base class presented in its derivation list! It refers to another base class that is not shown. Another problem with the same piece of code is apparently due to typesetting of the page. A couple string constants are split across lines in the listing, without utilizing the ANSI C string constant concatenation feature. If the reader attempts to type in this piece of code and compile it, (I tried!) s/he will be in for quite a surprise. Another minor nit is the one of the string constants presented within a printf() is missing a newline character. Some examples presented in the text have portability problems. One example class stores a two byte integer with the low and high bytes reversed. But the authors declare the data item as just int, depending upon the fact that an int is 16 bits on their machine. (a PC). An int may be something other than 16 bits on another machine. Another example, uses a string library function, strdup(), that is not part of the ANSI C standard string library, nor is it typically found in UNIX environments. Another problem was the inconsistency in the style used in examples. Example code is shown that exhibits two different styles of positioning a reference operator in a declaration. Regardless which style is preferable, consistency should be exhibited. Throughout the book the standard i/o library functions, eg. printf(), from C are used. Only towards the end of the book is the C++ stream i/o library covered. The authors indicate that they used the stdio functions throughout the book to avoid confusion and to keep from introducing too many new concepts at once. >The Weiskamp/Flamig book left me with a well rounded grip on >C++. It explained most everything, while stating differences >between V.1.2 and V.2.0 (There's also an appendice detailing >V.2.0 specifics and particularly, C++ vs. C differences. The >authors make generous use of what they call 'Tranlation Boxes' >which show what a C++ to C translator generates in 'C' code. >With these translation boxes, they provide good solid explanations >of how the C++ language achieves the OOP functionality which a >C++ programmer finds so to his liking. I thought that was fine the first time I saw it, but it gets to be a drag later on in the book when they try to explain advanced concepts in C++ and show their equivent forms in C. >The authors explain some of the rough issues of the language >as well, eg. the notion that assignment of classes leads to >a lot of data copying, etc.. I will admit that, unlike many primers, they do tackle the hard stuff and not just the easy stuff. I remember a C primer I once saw that didn't talk about pointers!!!! >You get the idea, though. Some authors have carefully considered >and empathized with the needs of their audience and some, have >just done a data-dump of what they know w. explanations and >examples. We must be talking about different audiences then. I found the W&F book too simplistic in it's approach. It is the type of book that will not be of much value after the initial learning process. The other books spoken of in this posting will be used for a long time...... >I'm reading the Dewhurst/Stark book as a follow-on >to the Weiskamp/Flamig book. I suspect I'll see other good >examples of 'technique' in there, beyond the definition of >the actual language. That is exactly what the introduction of D&S says: "This book is about how to program using C++. We discuss the details of how to use C++ features, as well as how to apply paradigms in design and implementation." >Anyway the Weiskamp/Flamig book is very very good. No it is not. It is mediocre at best. With a better review process, more realistic examples, and a more professional tone it would be adequate. >I highly recommend it. And then, I recommend such other texts >as the Dewhurst/Stark for supplemental reading afterwards. Get the Lippman book, then the other. Forget the W&F book. >And that's the experience of one person who has recently >learned both OOP and C++. Somehow, I doubt you have learned either yet. George George W. Leach AT&T Paradyne (uunet|att)!pdn!reggie Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA
hardin@hpindda.HP.COM (John Hardin) (05/10/90)
reggie@dinsdale.paradyne.com (George W. Leach) writes: > In article <4143@infmx.UUCP> briand@infmx.UUCP (brian donat) writes: > > [most of discussion deleted] > > >And that's the experience of one person who has recently > >learned both OOP and C++. > > Somehow, I doubt you have learned either yet. ---------- This kind of personal slur is totally uncalled for on the net. Besides being a demonstration of poor manners, it has the result of inhibiting people from openly sharing their opinions. I read with interest the opinions of both Mr. Leach and Mr. Donat on the books being discussed and was very disappointed to find this little barb tacked to the end. John Hardin hardin@hpindgh.hp.com -------