shehzad@babel.SanDiego.NCR.COM (Mevawalla Shezad) (03/30/89)
I have been assigned a new project which has to be written in C++ and therefore I need to learn C++ in a real hurry. Can someone please point me to some texts which are good for learning C++. I do know C, but I'm not very good at it. My strong languages are Pascal and Assembly. I already have the book " The C++ Programming Language" by Bjarne Stroustrup but I have been told that this is not a very good book for beginners. Any recommendations will be greatly appreciated. ----------------------------------------------------------------------------- Shehzad Mevawalla shehzad@babel.SanDiego.NCR.COM (619) 746-2461 ------------------------------------------------------------------------------
jeff@hpctdls.HP.COM (Jeff Hughes) (03/31/89)
I just learned C++ about a month ago myself. I found the book "An
Introduction to Object-Oriented Programming and C++" by Richard Wiener and
Lewis Pinson to be very useful.
After reading the text, I typed in a couple of examples from chapter 6.
These were the heterogenous linked list and search tree examples given
in listings 6.5 - 6.7 and 6.10 - 6.11. That should get you off to a good
start.
Good luck,
Jeffcs132046@brunix (Garrett Fitzgerald) (04/14/89)
In article <1990009@hpctdls.HP.COM> jeff@hpctdls.HP.COM (Jeff Hughes) writes: > I just learned C++ about a month ago myself. I found the book "An >Introduction to Object-Oriented Programming and C++" by Richard Wiener and >Lewis Pinson to be very useful. > After reading the text, I typed in a couple of examples from chapter 6. >These were the heterogenous linked list and search tree examples given >in listings 6.5 - 6.7 and 6.10 - 6.11. That should get you off to a good >start. Actually, I liked these examples too, and started planning a programming assignment using the friend-type syntax that they used--and then got hell from my TA for using friends. I was told that for real object-oriented programming, I couldn't access the inner structure of the objects like that; I could only write "object::set_x(int x1)" and "object::get_x" type routines to look at them. -------------------------------- "Take my Worf--please!" -- Data Sarek of Vulcan, a.k.a. Garrett Fitzgerald cs132046@brunix or st902620@brownvm.bitnet
wlp@calmasd.Prime.COM (Walter L. Peterson, Jr.) (04/14/89)
In article <4009@brunix.UUCP>, cs132046@brunix (Garrett Fitzgerald) writes: > In article <1990009@hpctdls.HP.COM> jeff@hpctdls.HP.COM (Jeff Hughes) writes: > > ... > > After reading the text, I typed in a couple of examples from chapter 6. > >These were the heterogenous linked list and search tree examples given > >in listings 6.5 - 6.7 and 6.10 - 6.11. That should get you off to a good > >start. > > Actually, I liked these examples too, and started planning a programming > assignment using the friend-type syntax that they used--and then got > hell from my TA for using friends. I was told that for real object-oriented > programming, I couldn't access the inner structure of the objects like that; > I could only write "object::set_x(int x1)" and "object::get_x" type routines > to look at them. > -------------------------------- I have to agree with your TA. There are seveal objections ( pun only slightly intended :-) ) to friends. From the "theoretical" standpoint, your TA is correct; that is not "real" object-oriented programming. Only the object itself, via methods defined on its class, should be able to access its fields. This is due to the simple fact that the implementation details of how the field data is handled is encapsulated in the object class definition. The details of how the class and its fields are implemented are not a matter for other methods and class to be concerned with. How does/can the other method "know" what type of data validation might be taking place within the access methods of the friend class ? It can't. It shouldn't. If you *REALLY* need to access a given field of an object in a particular function, then you should give some very serious thought to making that function a method on the class. There are also some very practical reasons for not using friends. What do you do if (I should say *WHEN*) the definition of the object class in question changes ? How many files do you have to search through to find the direct field accesses ? The object paradigm is supposed to, among other things, increase productivity by eliminating the need to do things like that whenever a change is made. As far as I'm concerned, the use of "friends" is a bad idea. The very existance of friends encourages "bad" habits. I think that it is analogous to allowing the use of (you should pardon the expression) "goto" in structured languages and should, like "goto", be avoided like the plague. With friends like that you don't need enemies. -- Walt Peterson. Prime - Calma San Diego R&D (Object and Data Management Group) "The opinions expressed here are my own and do not necessarily reflect those Prime, Calma nor anyone else. ...{ucbvax|decvax}!sdcsvax!calmasd!wlp
dlw@odi.UUCP (Dan Weinreb) (04/16/89)
> There are also some very practical reasons for not using friends. > What do you do if (I should say *WHEN*) the definition of the object > class in question changes? How many files do you have to search > through to find the direct field accesses? Easy. The friends are all explicitly mentioned in the class declaration, just as the function members are. Therefore, when the implementation of the class changes, you go to the class definition and use it to find the names of all the function members and all the friends. Then you check out each one, and update it as necessary. The key issue is that every friend must be mentioned explicitly in the class definition. If that requirement did not exist, I would agree with your criticisms. Because friends are mentioned explicitly, they are a lot like function members as far as control of scoping and firewalling against updates are concerned. In fact, friends solve some tough problems in object-oriented programming that are left unsolved by most o-o languages. Sometimes it is truly necessary to have a piece of code that is part of the implementation of two classes, and knows about the internals of each class. (You may never have run into this need, but it comes up frequently in larger, more advanced systems. I believe there are some good examples in the libg++ library.) In such a case, I find that usually the two classes are best considered to be "one module", in a sense; that is, they get maintained together as a unit, rather than independently. Obviously, you don't do things like this unless there is a good reason; but sometimes there really *is* a good reason. The multimethods of CLOS (and its antecedent, CommonLoops) are sort of the same thing, although scoping rules in CLOS are so different from those in C++ that it is somewhat hard to draw a close analogy. There is no attempt so solve the problem in Smalltalk-80; but Smalltalk-80 shies away from another important features needed by large, serious o-o programs, namely multiple inheritance, so perhaps it is just their policy. To the best of my knowledge, the friend feature is unique to C++; C++ has been particularly innovative in the area of name scoping, particularly the private/protected/public distinction, an idea that other o-o languages could learn from. Students in an introductory o-o programming course are highly unlikely to run into the need for functions that are friends of two classes. In fact, they are unlikely to need friends at all. If I were teaching such a course, I might indeed tell the students to never use the "friend" feature; not because it is a bad feature, but because it can confuse you if you are still learning basic o-o concepts. P.S. CLOS is the object-oriented part of the Draft ANSI Common Lisp language, based on CommonLoops and New Flavors.
ark@alice.UUCP (Andrew Koenig) (04/16/89)
In article <300@odi.UUCP>, dlw@odi.UUCP (Dan Weinreb) writes: > Students in an introductory o-o programming course are highly unlikely > to run into the need for functions that are friends of two classes. > In fact, they are unlikely to need friends at all. Imagine a linear algebra package with Matrix and Vector classes. A function that multiplies a Matrix and and a Vector is a logical candidate to be a friend of both. -- --Andrew Koenig ark@europa.att.com
dlw@odi.UUCP (Dan Weinreb) (04/18/89)
> Imagine a linear algebra package with Matrix and Vector classes.
All I meant was that I didn't think students in an *introductory* o-o
programming course would be writing such a linear algebra package.
Naturally it depends on the intensity of the course. A complete C++
course should certainly teach about the friend feature, but not right
at the beginning. I don't think we're really disagreeing.
-- Dan Weinreb Object Design, Inc. odi!dlw@talcott.harvard.edu