franco@olsen.UUCP (Franco Monti) (03/04/89)
Hi,
Allow me a question which may be trivial for you guys. I'm a
beginner of C++ and therefore interested in the following
flavour of inheritance:
In Smalltalk-80 you can use inheritance as in this sample program:
(***********************************)
class name One
superclass Object
instance methods
test
^1
result1
^self test
class name Two
superclass One
instance methods
test
^2
class name Three
superclass Two
instance methods
result2
^self result1
result3
^super test
(*************************************)
Now create new instances:
example1 <- One new
example2 <- Two new
example3 <- Three new
and consider scenarios like this:
expression result
---------- ------
example1 test 1
example1 result1 1
example2 test 2
example2 result1 2
example3 test 2
example3 result2 2
example3 result3 2
Now comes the tricky part: How can I translate the behavior of
the code outline above to the appropiate structures in C++ ?
How do you move *up and down* in a given class hierarchy,
like in my little example, using C++ ?
Is it possible to cover this examples with an easy to understand and well
structured program in C++, how is this best done ?
Could anybody give me a pointer ?
Thanx
Franco M. Monti
Olsen & Associates
Seefeldstr. 233
8008 Zuerich
Switzerlandcmc@inf.rl.ac.uk (Chris Crampton) (03/16/89)
In article <110@honold.UUCP> franco@honold.UUCP (Franco Monti) writes: > How can I translate the behavior of > the code outline [below] to the appropiate structures in C++ ? > ... > > class name One > superclass Object > instance methods > > test > ^1 > > result1 > ^self test > class One { public: virtual int test() { return 1; } int result1() { return test(); } }; // The "virtual" function is the key to what you are after. // Strictly speaking, the class could be a struct as there // are no private or protected declarations > > class name Two > superclass One > instance methods > > test > ^2 class Two : public One { public: int test() { return 2; } }; > > class name Three > superclass Two > instance methods > > result2 > ^self result1 > result3 > ^super test > class Three : public Two { public: int result2() { return result1(); } int result3() { return Two::test(); } }; // I am not quite sure how significant the "^super" is // in your example. Depending what you want, the "Two::" // may not be necessary. > > (*************************************) > > Now create new instances: > > example1 <- One new > example2 <- Two new > example3 <- Three new One example1; Two example2; Three example3; > > and consider scenarios like this: > > expression result > ---------- ------ > > example1 test 1 > example1 result1 1 > example2 test 2 > example2 result1 2 > example3 test 2 > example3 result2 2 > example3 result3 2 example1.test() 1 example1.result1() 1 example2.test() 2 example2.result1() 2 example3.test() 2 example3.result2() 2 example3.result3() 2 Hope this answers your question. Chris. ======================================================================= Chris M Crampton JANET: cmc@uk.ac.rl.inf Informatics Department ARPA: cmc%inf.rl.ac.uk@nss.cs.ucl.ac.uk Rutherford Appleton Labs, UUCP: ..!mcvax!ukc!rlinf!cmc Didcot, OXON, OX11 0QX, U.K. cmc@rlinf.uucp Tel. +44 235 44 6756 FAX. +44 235 44 5831
uucibg@sw1e.UUCP (3929]) (03/23/89)
In article <5481@rlvd.UUCP> cmc@inf.rl.ac.uk (Chris Crampton) writes: >In article <110@honold.UUCP> franco@honold.UUCP (Franco Monti) writes: >> How can I translate the behavior of >> the code outline [below] to the appropiate structures in C++ ? > [A very good translation from some Smalltalk code to some C++ code] >Hope this answers your question. Just a quick note: While it may be possible to port large portions of many classes from Smalltalk-like languages to C++, there are some definite problems. The biggie is of course the fact that C++ uses strong typing of objects (e.g. determine at compile time what function/method is to be invoked ) while Smalltalk and Smalltalk-like languages use weak typing of objects and actually accomplish function address resolution at run-time. The net result of this is that in Smalltalk-like languages you can try to invoke any method of (send any message to/ invoke any member function of) any object. If the object's class doesn't implment the method (message/function) then the method (function/ essage) resolution code will detect such a condition. The resolution code will then often invoke the object's "error" method (send the error message/invoke the error function). In a nutshell: In Smalltalk-like languages, class references (refs to objects) are not typed and you can send them any message you want to. In C++-like languages (or Eiffel-like languages, etc.), references to objects are typed and you can only send a message to an object (invoke an object's function) if the object's class definition included mention of that message (method, function). I'd be interested to discuss the plusses/minuses of each approach here or in comp.misc or comp.compilers or where ever seems appropriate. But please, no flames, though corrections would be appreciated. Brian R. Gilstrap Southwestern Bell Telephone One Bell Center Rm 17-G-4 ...!ames!killer!texbell!sw1e!uucibg St. Louis, MO 63101 ...!bellcore!texbell!sw1e!uucibg (314) 235-3929 #include <std_disclaimers.h>
hearn@claris.com (Bob Hearn) (03/25/89)
In article <1411@sw1e.UUCP> uucibg@sw1e.UUCP (Brian Gilstrap [5-3929]) writes: >The biggie is of course the fact that C++ uses strong typing of objects (e.g. >determine at compile time what function/method is to be invoked ) while >Smalltalk and Smalltalk-like languages use weak typing of objects and actually >accomplish function address resolution at run-time. The net result of this is Well, yes, but you *do* have virtual functions in C++, which give you most of the functionality you want. The prototypical example is the graphic object class that has a virtual draw function that is redefined for each derived class, so you can have a ptr to a graphic object without knowing what specific type it is, tell it to draw, and have the correct function be called (determine at run time). This example is actually quite applicable to what I am doing: writing an object-oriented graphics package in C++. One problem I found with virtual functions was this: I wanted to have a graphic object class, and I wanted to have a graphics database class which would store graphic objects in a list and know how to manipulate them. One of the things the graphics database should do is take a ptr to a function and apply it to every object in the database. Well, one problem right off is that sometimes the func. should take the object as a parameter, but often it would be convenient to use a graphic object member function, so the object would be an implicit parameter, and the parameterization would be different. OK, no problem there, just overload the traversal member func (the one that applies the function). But this is a problem: suppose the graphics database is supposed to be packaged up as a utility to be used by a lot of different clients, each of whom may want their objects to do different things. The natural thing to do is derive new object classes off of the original graphic object class. But wait -- now I want to use a member function of this derived object class to pass to the database's traverse function, so it can be applied to all the objects. But, since the database was written without knowledge of the derived class, I can't know in advance the type of the function parameter to the traverse functions, specifically, the class it is a member function of (this won't make sense to those of you who don't have member function ptrs in your C++; they're an extension). At first, I gave up and just decreed that if you want to do this sort of thing, you must create a flat function as an interface from the traverse function to your new class, and pass that instead of the member function. But this is an extra level of indirection, and nothing can be inline here. Well, eventually I found a hack to make it work: turns out that, at run time, the only thing that distinguishes one member function ptr from another is whether or not it's virtual. If the base object class has no virtual functions, then when you apply a member func. ptr to objects of that class it assumes the ptr is to a 'real' function; it doesn't check to see if it's virtual. But of the base class *does* have virtual functions, it checks to see whether the member func ptr is real or virtual. If it's virtual, it looks up the function in the object's class, which can be determined at run time, because members of classes with virtual functions all have ptrs to their class's virtual function table. So, if I cast the ptr to member function of derived class to a ptr to member function of base class, where the base class has virtual functions, then it works! Ta da. Aren't you glad you read this all the way to the end? :-) Bob Hearn hearn@claris.com
uucibg@sw1e.UUCP (3929]) (03/25/89)
In article <9174@claris.com> hearn@claris.com (Bob Hearn) writes: >In article <1411@sw1e.UUCP> uucibg@sw1e.UUCP (Brian Gilstrap [5-3929]) writes: >>The biggie is of course the fact that C++ uses strong typing of objects (e.g. >>determine at compile time what function/method is to be invoked ) while >>Smalltalk and Smalltalk-like languages use weak typing of objects and actually >>accomplish function address resolution at run-time. The net result of this is > >Well, yes, but you *do* have virtual functions in C++, which give you most >of the functionality you want. ... [ One *seriously* archaic though (as near as I can tell) quite accurate ] [ description ] >So, if I cast the ptr to member function of derived class to a ptr to member >function of base class, where the base class has virtual functions, then >it works! Ta da. Aren't you glad you read this all the way to the end? :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ yes. :-) >Bob Hearn >hearn@claris.com Your comments do bring up several points, which I would like to *DISCUSS* if anyone else is interested. There has already been too much bashing of various kinds lately, and I do *not* want to start a religious war. So if you feel particularly strongly about what I say here, send me private email (and I can quietly dump the flames :-) but Please don't flame back to the group. I find, the more I deal with C++, the more concepts I have deal with. For me, worrying about whether a base class contains virtual functions or not in order to assure appropriate selection of a function based upon member function pointers is rather hairy. Yes, I can figure out what's going on. Do I want to? Not really. If I have to spend all my time worrying about these kinds of things, then I won't get any work done. I certainly realize that there is a learning curve to C++. But It seems that there's *so* much to learn. I was my understanding that the whole purpose of OOP was to make life easier on programmers overall. It certainly requires a great deal more design time than functional programming, but in the long run will (we hope) save us lots of hassle. However, I don't see that happening in C++ yet. It seems to be getting more and more complex. I recently read Bjarne Stroustrup's article in the latest issue of JOOP about parameterized types in C++. It boggled my mind. Sure I figured out what he was talking about, and yes I could decipher the code. But it's all so complicated with so many exceptions that it begins to seem like it's not worth the effort to learn. This seems especially true when I start to look at other OOP languages which have grafted Smalltalk classes/objects onto C (note that Objective-C is not the only one). In these cases, you have to learn one particular extension to C and then you're done with the new concepts. Another point (and I'm going to go way out on a limb here): it seems like the concept of objects is made rather complex by the use of static/strong typing. This is what get's you into all the issues of virtual functions and parameterized types. Yes, I realize that weak typing introduces its own problems. But I'm beginning to conclude that the weak-typing problems are easier to deal with than the strong-typing ones. I do realize that C++ was intended to improve C in many ways, just one of which was object-oriented-ness. I also realize that Bjarne Stroustrup also wanted to keep C++ as efficient as possible (in the spirit of C). I think that it's a very admirable idea. However, it seems that the cost we pay for all that possible efficiency is complexity. I'm not sure that the efficiency gained will really be worth it (though there will of course always be applications which push the limits). Please respond rationally. Brian R. Gilstrap Southwestern Bell Telephone One Bell Center Rm 17-G-4 ...!ames!killer!texbell!sw1e!uucibg St. Louis, MO 63101 ...!bellcore!texbell!sw1e!uucibg (314) 235-3929 #include <std_disclaimers.h>
keffer@blake.acs.washington.edu (Thomas Keffer) (03/26/89)
In article <1421@sw1e.UUCP> uucibg@sw1e.UUCP (Brian Gilstrap [5-3929]) writes: >I find, the more I deal with C++, the more concepts I have deal with. For me, >worrying about whether a base class contains virtual functions or not in order >to assure appropriate selection of a function based upon member function >pointers is rather hairy. Yes, I can figure out what's going on. Do I want >to? Not really. > >I recently read Bjarne Stroustrup's article in the latest issue of JOOP about >parameterized types in C++. It boggled my mind. Sure I figured out what >he was talking about, and yes I could decipher the code. But it's all so >complicated with so many exceptions that it begins to seem like it's not >worth the effort to learn. I couldn't agree more! I am NOT a computer scientist. But, I AM a good programmer. It's just that I don't LIKE to learn all the intricate details of a complicated language. (You can have virtual destructors, but not constructors; arrays of objects need an unadorned constructor; etc.) Now, don't get me wrong --- I certainly CAN learn the details and I have picked up C++ (relatively) quickly. But that's not my objective, certainly not my life. Watching other people trying to pick up the language has been a painful (and embarassing... usually they do it at my behest) experience. Example: I had one undergraduate working with me on a REU (Research Experience for Undergraduates) project who spent most of the year just learning the language. He never did get much accomplished on the OBJECTIVE of the project. And this guy is not dumb. He's just not a computer scientist and/or a compulsive hacker. We are going to lose these guys. Can we afford to? I think not. I have real doubts that C++ will ever break out of the cadre of pure CS professionals. It's not like C++ is C but, gee, if you want to, you can learn a little bit and get a little bit of extra functionality in your code. This is not a linear transfer function! To add ANY new functionality, you must learn a LOT. What to do? It seems to me there are 6 main _PRACTICAL_ problems now 1) Poor quality compilers. You never know if it's you or cfront. 2) Few gurus. 3) Few "known correct" examples of non-trivial code. 4) Only two books, neither of them very good. 5) Few precanned, bulletproof classes. 6) Steep learning curve, especially to learn writing new classes. Of these, 1 through 5 will eventually go away. 6 never will. If we are lucky, the language may evolve into one where the majority of the users will combine old classes in new ways, perhaps making trivial modifications to them. I have real doubts, though, that you'll ever see millions of programmers out there writing new classes the way you see them writing new C code. --- Dr. Thomas Keffer | Internet: keffer@sperm.ocean.washington.edu School of Oceanography | BITNET: keffer%sperm.ocean.washington.edu@UWAVM Univ. of Washington, WB-10 | uucp: uw-beaver!sperm.ocean.washington.edu!keffer Seattle, WA 98195 | Telemail: T.KEFFER/OMNET (206) 543-6455
fabbott@athena.mit.edu (Freeland K Abbott) (03/26/89)
In article <1335@blake.acs.washington.edu> keffer@blake.acs.washington.edu (Thomas Keffer) writes: >What to do? It seems to me there are 6 main _PRACTICAL_ problems now > >1) Poor quality compilers. You never know if it's you or cfront. Obligatory plug for g++, a native compiler... which admittedly has its own problems as well... >2) Few gurus. Nice to be on the cutting edge, right? :-) >3) Few "known correct" examples of non-trivial code. Mmm. I see lots of correct code, but only in a limited range of applications. But the application I'm working on at Lotus is written in C++, which is why I'm trying to learn it... >4) Only two books, neither of them very good. By now, I bet there're more than two books. If not, I'd be happy to write one! In a few months at least, that is... >5) Few precanned, bulletproof classes. This is what I see as the real potential strength of C++. Eventually, I think you'll have huge libraries of classes which people will link to to do much of anything. But yes, most will probably do it in C... >6) Steep learning curve, especially to learn writing new classes. MIT has a course for freshmen which teaches OOP concepts (they use scheme, a dialect of LISP, though). I don't know... I was exposed to the ideas at work first, so they don't seem as bizarre as they do to some of my classmates, but I still don't think they're that hard to grasp. I think most of the learning curve comes from having to deal with the typing problems (that's what gives me headaches...), and I think that with time (a) people will figure out how to deal with them and will be able to pass that along, and (b) most of the really ugly ones will be buried in the previously mentioned library. Freeland K. Abbott fabbott@athena.mit.edu 454F 410 Memorial Drive MIT Undergrad (undeclared) Cambridge, MA 02139 USA "stop the world, I want to get off..."
rkr@june.cs.washington.edu (R. K. Raj) (03/26/89)
In <1335@blake.acs.washington.edu> Thomas Keffer writes: >In <1421@sw1e.UUCP> Brian Gilstrap writes: >>parameterized types in C++. It boggled my mind. Sure I figured out what >>he was talking about, and yes I could decipher the code. But it's all so >>complicated with so many exceptions that it begins to seem like it's not >>worth the effort to learn. >I couldn't agree more! > >I am NOT a computer scientist. But, I AM a good programmer. It's >just that I don't LIKE to learn all the intricate details of a >complicated language. (You can have virtual destructors, but not > Dr. Thomas Keffer | Internet: keffer@sperm.ocean.washington.edu > School of Oceanography | BITNET: keffer%sperm.ocean.washington.edu@UWAVM I couldn't agree more either! I AM a computer scientist (got two CS degrees to write home about, anyway :=). And I'd say I am a good programmer, but perhaps a lousy hacker. The real problem is that there aren't any *good* object-oriented languages (outside the research world, and even inside!) that have efficient implementations for people to use for practical programming. While the design and implementation of C++ shows a brilliant way of adding "object-oriented"ness to C, there's only so much that can be done to C (or for that matter to any existing language). There is rather like Fortran; none of the various dialects, Fortran-77 before/after, can really hide the face of Fortran from seeping through. There are times when it makes sense to start off with a clean slate, and this is one such occasion. Unfortunately, I think that the time/money/effort that will be spent on C++ guarantees that we all are doomed (destined if you object :=) to become expert C++ programmers. Or stick to Fortran :=) - R. K. Raj rkr@june.cs.washington.edu rkr@uw-june.UUCP
coggins@coggins.cs.unc.edu (Dr. James Coggins) (03/27/89)
In article <1335@blake.acs.washington.edu> keffer@blake.acs.washington.edu (Thomas Keffer) writes: > >What to do? It seems to me there are 6 main _PRACTICAL_ problems now > >1) Poor quality compilers. You never know if it's you or cfront. >2) Few gurus. >3) Few "known correct" examples of non-trivial code. >4) Only two books, neither of them very good. >5) Few precanned, bulletproof classes. >6) Steep learning curve, especially to learn writing new classes. Assuming that being a "Computer Scientist" has not become anathema in this community, I'll respond. C++ has caught on so quickly that the community has gotten ahead of the normal language (and environment) development process. Thus, your complaints 1-5. We're working on it. The language is evolving (and in particular, C++ Version 2 is in beta test now, so I hear), so those of us who are computer scientists whose lives are indeed intertwined with this programming language and who could serve as gurus and authors of superior textbooks are frozen -- we can't publish great educational material based on Version 1.2 since it would be obsolete before the first copies came off the press. Nevertheless, I am preparing to release my C++ class library next month, which you will find to be "in regular use, believed mostly correct, highly nontrivial code". And apparently written in an idiom that does not encounter many of the difficulties I keep reading about in this newsgroup. (When people have come to me asking about how to do some weird thing in C++ I usually have found there to be fundamental design idiocies. Correcting them made the weird thing unnecessary.) Stroustrup's book is fine, but its objective was not to serve as a tutorial; it does not address the objective you seek. The other book I have seen was intended to be a tutorial; it is just poor. "Precanned, bulletproof classes" as are commonly practiced (well, attempted) in this community are probably not such a great idea in general, anyway. Application-area-specific sets of class hierarchies aiming at encapsulations of rather large concepts relevant to the application area are probably a better way to build meaningful, reusable classes than the Single Monolithic Hierarchy (like Smalltalk and the NIH classes) and are certainly better than building a house from grains of sand (like building "stack" and "linked list" and "hash table" classes and then applications atop them -- yech). >Of these, 1 through 5 will eventually go away. 6 never will. Ridiculous. Maybe my advantage is that I never learned C before learning C++. The concept of "class" is so intuitively appealing that it improves program design immediately. Maybe you need some more useful examples? Learning C++ with an experienced guide does not take long at all. I have demonstrated this fact by teaching portions of my class hierarchy and its use in three lectures plus several example programs. It was not easy, but we did it. Students were writing programs using the classes in rather sophisticated ways within a week. True, they were not writing new classes themselves, but several asked about how to do it and in fact did it, starting by modifying some of my classes. I think people are looking a learning UNIX/C through rose-colored glasses. I have not found sockets and interprocess communication to be so trivial. Neither have I found SunView or X to be trivial. Neither is the Smalltalk class hierarchy or its environment trivial. C++ is not trivial, but with a careful and correct presentation, it's easier to follow than some of these other systems. Teaching C++ to Pascal programmers is a bit easier than teaching it to C programmers, I think. Pascal programmers have a more well-developed aesthetic sense and resonate better with C++ concepts. Even then, the presentation must be carefully designed so that people think about programs differently and don't just pick up a new hammer (and therefore see the world as a collection of new-age nails). The same kinds of cries arose from software developers in client disciplines when Structured Programming was the rage in the late '70's. "What are those computer scientists doing?" "Why not leave well enough alone?" "I went to one of their meetings and they were arguing about such trivia that I just walked out." "If it ain't broke don't fix it." And the ever popular, "Why should I care about this new development? I can do everything I want to do in FORTRAN." To summarize: We computer science folks are aware of the problems. Many of us are waiting for C++ Version 2.0 before releasing our contributions since they'll all change then anyway. Whether the ideals of "code sharing" should be implemented by a single monolithic hierarchy, a collection of small implementation classes or as hierarchies fitting concepts of the application area (my preference!) is still open for debate. C++ is different, but there is no reason to believe that learning and using C++ will be any more difficult than learning a few new features of UNIX/C. >--- > Dr. Thomas Keffer | Internet: keffer@sperm.ocean.washington.edu --------------------------------------------------------------------- Dr. James M. Coggins coggins@cs.unc.edu Computer Science Department UNC-Chapel Hill Old: Algorithms+Data Structures = Programs Chapel Hill, NC 27599-3175 New: Objects+Objects=Objects and NASA Center of Excellence in Space Data and Information Science ---------------------------------------------------------------------
bs@alice.UUCP (Bjarne Stroustrup) (03/27/89)
Naturally, C++ is complex, but I don't think it is as complex as it is
sometimes made out to be, nor do I think programming in other languages
is as simple as it is sometimes made out to be for roughly similar
problems and roughly similar constraints of the solution.
An example: My paper on a proposed facility for a parameterized type
facility was mentioned. It is about 20 pages long. It is not the easiest
paper to read, though again I doubt you'll find a significantly simpler
discussion of the issues in the litterature.
The paper describes a proposed scheme, it describes alternative
implementation strategies for the proposed scheme, it describes many
features and variants of features - including many rejected ones.
It is most certainly not a tutorial. It is a discussion about details
of language design and implementation techniques. Of the 20 pages about
2 are devoted to the language feature itself and its use.
A reference manual entry for parameterized types is about 2 pages. The
feature itself is fairly trivial to learn and use. The complexity in the
paper is in the discussion of alternatives and implementation details -
not in the feature itself.
Let me try to substatiate this statement by explaining the basics of
the proposed parameterized type facility right here. The idea is
simple: It should be possible to provide a user-defined type (i.e. class)
with an argument left for the user of the type to specify. For example:
vector<int> vi(10); // vector of 10 integers
vector<complex> vc(20); // vector of 20 complex numbers
vector<char*> vs(40); // vector of 40 pointers to char
The declaration of class vector looks like this:
template<class T> // The class declared here takes
// a type as an argument.
// The argument type is called T
class vector {
T* v;
int sz;
public:
vector(int s) { v = new T[sz=s]; }
~vector() { delete v; }
T& operator[](int i) { return v[i]; }
int size() { return sz; }
};
Complex? Not really. The only difference from C++ as we have it today is
the specification of the argument `T' in the template declaration and the
use of the vector<int>, vector<complex>, etc. to use it. Compare the
complexity to what you will have to write to fudge this facility in a
language that does not provide it or to use a similar facility in a
language that does provide such a facility.
I will not reinforce the appearance of complexity by discussing details,
implementation issues, and alternatives here. My point is that if you
understand the basics of C++ you now also understand enough about `templates'
(the term chosen for parameterized types in C++) to use them. If you are
interested details have a look at my paper: Parameterized Types for C++.
You can find it either in the January issue of JOOP or in the proceedings
of the Denver USENIX C++ conference. It might be worth pointing out that
templates are not part of C++ as currently shipped nor is it part of
release 2.0.bs@alice.UUCP (Bjarne Stroustrup) (03/27/89)
Dr. Thomas Keffer, School of Oceanography,Univ. of Washington writes: > It seems to me there are 6 main _PRACTICAL_ problems now > 1) Poor quality compilers. You never know if it's you or cfront. Definitely a problem. C++ usage has grown too fast. Most people are working with first generation compilers and tools. My impression is that the quality of compilers and other tools is improving fast. The fact that there is already real choices for the users guarantees that. My guess is that this problem will disappear. Come fall most people will have access to second generation compilers and tools. > 2) Few gurus. Definitely a problem, but how do you get enough gurus for something that is not a trivial rethread of something well known and where the number of users more than double every 6 month? I see no alternative to providing better courses, better books, etc. This takes time. Many people started last year. The effect will be felt this year. > 3) Few "known correct" examples of non-trivial code. How would you expect to get that for a relatively new language? The only way I can think of would be to keep it from users until a large body of code was very widely available. That was the C and Smalltalk way of solving the problem. With C++, people were in no mood to wait. > 4) Only two books, neither of them very good. I hestiate to comment on the quality issue, but I have seen four C++ books in print in English plus two in Japanese and one in German. In addition, there is quite a few papers, in particular the proceedings of the USENIX C++ conferences. C++ is also nicely explained in Ravi Seti's new text book on programming languages. Finally, I agree, even this isn't good enough, but fortunately there is at least six C++ books with a tutorial bend in the late stages of developent. Again, I expect the diversity will enforce a trend towards quality and a trend towards specialization that will help specific groups. > 5) Few precanned, bulletproof classes. For those to exist somebody has to write them and make them available. You can get that either by delaying the availability of the language or by making the language proprietary (thus creating a captive market making library writing a safe lucrative business). Otherwise, there will be a delay between the appearance of the language and the appearance of large libraries. Proprietary, public domain, and `free' libraries are beginning to appear. > 6) Steep learning curve, especially to learn writing new classes. I conjecture that is primarily a result of the relative newness of the language and of the lack of experience with data abstraction and object oriented programming in general among programmers (yes I know that thousands have genuine experience, but they are drowned by the hundreds of thousands of programmers that do not). In other words, 6 is a simple consequence of 1,2,3,4,and 5. Since 1,2,3,4,and 5 are being taken care of the effort of learning to use C++ well will decrease noticeably. Greater awareness and better teaching of data abstraction and object oriented programming in general will do the rest. So I agree with Dr. Keffer's observations, but not with his conclusion: > 1 through 5 will eventually go away. 6 never will. If you don't feel comfortable with the current state of C++ just leave it alone for a few months (or forever if you wish). Hopefully, nobody is forcing you to use it. What you are seeing (including your #6) is the result of explosive growth and is being taken care of by many individuals and organizations.
bright@Data-IO.COM (Walter Bright) (03/28/89)
In article <1421@sw1e.UUCP> uucibg@sw1e.UUCP (Brian Gilstrap [5-3929]) writes: >I find, the more I deal with C++, the more concepts I have deal with. >I certainly realize that >there is a learning curve to C++. But It seems that there's *so* much to >learn. I agree that C++ is a difficult language to master. I suspect that it is also the wrong language for a novice programmer. The more I work with C++, the more it seems a bit like calculus. It's a powerful and elegant tool once mastered, but in learning it there is no substitute for effort and work. I've seen textbooks (mainly economics and business ones) that went to great lengths with algebra to demonstrate something that could have been shown with a simple derivative. The effort to avoid calculus was substantial, and produced a mess of things. The same thing has happened in programming. Some programs and packages work very naturally in C++, doing them in C is certainly possible, but the result is ugly, clumsy and bug-prone. (BTW, I think everyone should learn the basics of Calculus! :-) ) The C community has been around for many years now, and has learned how to use C and how to teach C. There are now universally acknowledged do's and don'ts, including style do's and don'ts. C++ is a young language, and judging from the code I've seen, the C++ community is still groping about trying to figure this out. I have no doubt, though, that it will mature and things won't look so inscrutable anymore.
uucibg@sw1e.UUCP (3929]) (03/28/89)
In article <9108@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes: >An example: My paper on a proposed facility for a parameterized type >facility was mentioned. It is about 20 pages long. It is not the easiest >paper to read, though again I doubt you'll find a significantly simpler >discussion of the issues in the litterature. >A reference manual entry for parameterized types is about 2 pages. The >feature itself is fairly trivial to learn and use. The complexity in the >paper is in the discussion of alternatives and implementation details - >not in the feature itself. I must agree that this is true. My previous article should not have used the parameterized types paper as an example of undue complexity in C++, since the article dealt with design issues for possible additions to C++, rather than the language itself. I would still be interested in discussions/{pointers to articles} which discuss the issues of strong vs. weak typing in conjunction with object-oriented design and languages (I suppose such discussions ought to go into comp.lang.misc since they are only somewhat related to C++; anyone know of any articles on the subject?). Brian R. Gilstrap Southwestern Bell Telephone One Bell Center Rm 17-G-4 ...!ames!killer!texbell!sw1e!uucibg St. Louis, MO 63101 ...!bellcore!texbell!sw1e!uucibg (314) 235-3929 #include <std_disclaimers.h>
klt@ntcsd1.UUCP (Kristopher L. Tyra) (03/28/89)
In article <7668@june.cs.washington.edu> rkr@uw-june.UUCP (R. K. Raj) writes: >I AM a computer scientist (got two CS degrees to write home about, anyway :=). >And I'd say I am a good programmer, but perhaps a lousy hacker. > >The real problem is that there aren't any *good* object-oriented languages >(outside the research world, and even inside!) that have efficient >implementations for people to use for practical programming. While the >design and implementation of C++ shows a brilliant way of adding >"object-oriented"ness to C, there's only so much that can be done to C (or >for that matter to any existing language). There is rather like Fortran; >none of the various dialects, Fortran-77 before/after, can really hide the >face of Fortran from seeping through. > >There are times when it makes sense to start off with a clean slate, and >this is one such occasion. Unfortunately, I think that the time/money/effort >that will be spent on C++ guarantees that we all are doomed (destined if you >object :=) to become expert C++ programmers. Or stick to Fortran :=) > > - R. K. Raj > rkr@june.cs.washington.edu > rkr@uw-june.UUCP I think the real problem has come out. C++ is not really designed to be smalltalk or even Objective-C it is designed to be an enhancment to C ( hence C++ :-) ). If you need to do list processing you don't use Fortran you use LISP. My point is that Computer Science has developed a rich set of tools to solve problems at different levels ( USE THEM ! :-) ). 'C' has been forced into markets it was never intended to be in. My suggestion is not to do the same with C++. If you need week typing and strong OOP use smalltalk. Ok, smalltalk is inefficient and slow, but don't try and run an image processing task on a PC/AT either. We use C++ here at Northern to give 'C' software maintainance capabilities that just weren't there in 'C'. We use both the object oriented features and the strong typing and it becomes very usefull for our purpose. However, we do not try and use Gorlen's OOPS package because it takes the language to it's farthest extrems ( Don't get me wrong, the package has some very good work in it ). In doing this, we end up generating hard to read code and I think all here would agree the major problem in Software is re-use and maintainance. So to summarize, it is good that we suggest the corrections and changes in the language to make it a more refined language. But don't attempt to make the language something it is not! Kristopher L. Tyra Northern Telecom, Inc. 800 Perimeter Park Raleigh, NC 27595 (919) 481-5595 klt@mcnc!rti!ntcsd1
plogan@mntgfx.mentor.com (Patrick Logan) (03/29/89)
In article <7431@thorin.cs.unc.edu> coggins@coggins.cs.unc.edu (Dr. James Coggins) writes: => In article <1335@blake.acs.washington.edu> keffer@blake.acs.washington.edu (Thomas Keffer) writes: => >What to do? It seems to me there are 6 main _PRACTICAL_ problems now => >1) Poor quality compilers. You never know if it's you or cfront. => >2) Few gurus. => >3) Few "known correct" examples of non-trivial code. => >4) Only two books, neither of them very good. => >5) Few precanned, bulletproof classes. => >6) Steep learning curve, especially to learn writing new classes. => => ... => => Nevertheless, I am preparing to release my C++ class library next => month, which you will find to be "in regular use, believed mostly => correct, highly nontrivial code". And apparently written in an idiom => that does not encounter many of the difficulties I keep reading about => in this newsgroup. (When people have come to me asking about how to do => some weird thing in C++ I usually have found there to be fundamental => design idiocies. Correcting them made the weird thing unnecessary.) These weird tendencies can be attributed in part to the lack of good material explaining how to use C++ effectively. As Dr. Coggins indicates, better material should become available as experience is gained and C++ becomes less of a moving target. However, the language design contributes to the problem as previous posters have mentioned. Its mechanisms are non-orthogonal (e.g. using constructors with arrays of objects), non-perspicuous (e.g. a data member attributed with the keyword 'static' means that member is a class variable rather than an instance variable), and complicated (e.g. no automatic garbage collection). I know there are reasons for the language being the way it is and I accept them. (So no flames, please.) But I also believe they can make the language difficult to learn and use. => ... => Application-area-specific sets of class hierarchies => aiming at encapsulations of rather large concepts relevant to the => application area are probably a better way to build meaningful, => reusable classes than the Single Monolithic Hierarchy (like Smalltalk => and the NIH classes) and are certainly better than building a house => from grains of sand (like building "stack" and "linked list" and "hash => table" classes and then applications atop them -- yech). A few reactions: first, the idea of creating application-specific classes related to the relative concepts of the application. I think this is the best advice possible and is not emphasised enough. If the application's major components correspond cleanly to the major concepts then it will be easier to understand, modify, reuse, and extend, no matter how those classes are implemented. I agree that the "Single Monolithic Hierarchy" (SMH) is not the way to go at this time. Not because an SMH is a bad idea, but because C++ is not being designed to have one. I also agree that "building a house from grains of sand" is an empty strategy in and of itself. Stacks, linked lists, and hash tables, etc. are nice things to have. As are numbers, strings, and booleans. But in these days of object-oriented programming they are the least interesting things to have. It may be that a lot of programmers learn C++ and then proceed to use it to build their data structures and then plug them in to their C-like (or perhaps Modula/Ada-like) programs. There are some useful class hierarchies, though, somewhere between the SMH and a flat collection of data structures. For example, when some algorithm only needs the most general concepts of a collection, it should not have to know whether any particular collection is implemented as a hash table, linked list, array, or whatever. => >Of these, 1 through 5 will eventually go away. 6 never will. => => Ridiculous. => ... => The concept of "class" is so intuitively appealing that it improves => program design immediately. I don't think it's so ridiculous. I think C++ is complicated, not designing classes conceptually. Time will tell, everyone will have their own experiences. => Neither is the Smalltalk class hierarchy or its environment trivial. Triviality is not expected, although it's always welcome. The difference is the Smalltalk language lends to understanding where many aspects of C++ detract from understanding... in my *opinion*! And, yes, all of you flamers with your pilot lights ready, I know that in many ways C++ is more efficient than Smalltalk. I know there are advantages to both. Only send bits my way if you really need to. => > Dr. Thomas Keffer | Internet: keffer@sperm.ocean.washington.edu => Dr. James M. Coggins coggins@cs.unc.edu -- Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan Mentor Graphics Corporation | plogan@pdx.MENTOR.COM Beaverton, Oregon | (Remember I represent my self, not Mentor.)
reggie@dinsdale.nm.paradyne.com (George W. Leach) (03/29/89)
In article <404@ntcsd1.UUCP> klt@ntcsd1.UUCP (Kristopher Tyra) writes: >I think the real problem has come out. C++ is not really designed to be >smalltalk or even Objective-C it is designed to be an enhancment to C ( >hence C++ :-) ). If you need to do list processing you don't use Fortran you >use LISP. My point is that Computer Science has developed a rich set of >tools to solve problems at different levels ( USE THEM ! :-) ). That is correct. And furthermore, that is the way it should be. However........... >'C' has been forced into markets it was never intended to be in. There is a reason for this. The reason is that C can be applied to lots of applications, even some for which it was not intended and it still holds up well. It is difficult to justify to management that one must learn a barrage of languages in order to get something done. Training and learning curves are major issues. And how often have you seen a project where the language, hardware, os, etc.... has been dictated by either company policy or some marketing consideration, not by the programmers? Don Norman points out in some of his writings on design (not just program design) that often one must try to think of unintended uses that a customer might make of a product and be prepared for them. >My suggestion is not to do the same with C++. If you need week >typing and strong OOP use smalltalk. Ok, smalltalk is inefficient and >slow, but don't try and run an image processing task on a PC/AT either. Oh, but people will try. The attractiveness of the low cost PC as a platform will get all sorts of people to attempt to do things for which it was not intended. George W. Leach AT&T Paradyne .!uunet!pdn!reggie Mail stop LG-129 reggie@pdn.paradyne.com P.O. Box 2826 Phone: (813) 530-2376 Largo, FL USA 34649-2826