Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!kth!draken!Urd!newsuser From: newsuser@LTH.Se (LTH network news server) Newsgroups: comp.lang.c++ Subject: C++ Class Library Survey (COMMENTS) Message-ID: <1989Mar13.104021.696@LTH.Se> Date: 13 Mar 89 09:40:20 GMT References: <1989Mar13.103303.630@LTH.Se> Reply-To: dag@Control.LTH.Se (Dag Bruck) Organization: Dept. of Automatic Control, Lund Inst. of Technology, Sweden Lines: 188 The C++ Class Library Survey I posted not only resulted in people sending in completed forms, but also in some interesting (to me...) comments in comp.lang.c++. I have taken the liberty of compiling these comments from people well known to regular readers of this newsgroup. I hope we can continue the discussion, and also solve the practical problems of sharing C++ libraries. Dag M. Bruck Department of Automatic Control dag@control.lth.se Lund Institute of Technology, Sweden =============================================================================== In article <1989Feb27.090941.18193@LTH.Se> dag@Control.LTH.Se (Dag Bruck) writes: >We all want good, reusable C++ class libraries, and other useful tools. >I've expected to see a lot, but so far in vain. Now it's time to find out! > >If you have any code you think is useful, or have heard of some, try to >answer the questions below. I won't mind how ``trivial'' it may look -- >I want to see hundereds of linked list classes. Include any other tools, >class browsers, debuggers, you name it. Even if your code is not >generally available, please reply -- it would be interesting to know >what's going on. One thing that you should point out is that the code doesn't need to be good. I have discussed with various people why OOP class sharing hasn't taken off in the way it was expected to, one of the main reasons I've found is self conciousness, that is they don't want people to see the disgusting hacks that most programmers produce. When I'm reusing code I don't really care if it is disgusting, all I want o do is use it! It would be good if you could emphasis this (unless you disagree of course.) Another problem is that people are "just getting around to documenting the code". Code is pretty naff without documentation, but it is still useful. I find it easier to read code that write it, so I'm prepared to do a bit of work to document the code myself. i.e. code with no documetation is better than no code at all. And if the writter ever gets around to documenting the code, this could also be made avaliable (in fact, someone else, who had done the work to understand the code could even write the documentation and make it avaliable.) One thing you don't make clear is how to get hold of the code and documentation. What might be good would be if someone became an editor, and perhaps posted regular digests in comp.unix.sources (I supposed this would have to be discussed with the moderator though). Comments anyone? Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk =============================================================================== In article <2491@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >In article <1989Feb27.090941.18193@LTH.Se> dag@Control.LTH.Se (Dag Bruck) writes: >>We all want good, reusable C++ class libraries, and other useful tools. >>I've expected to see a lot, but so far in vain. Now it's time to find out! >> >I have discussed with various people why OOP class sharing hasn't >taken off in the way it was expected to, one of the main reasons I've >found is self conciousness, that is they don't want people to see the >disgusting hacks that most programmers produce. > Some time ago I made similar points in the article where I posted my FFT server code. There were no responses and there have been no followups with postings of other interesting classes. Programming is still very much a private art, not a public practice (tip of the hat to Gerald Weinberg). A deeper reason for the lack of class sharing, though, is that while classes are intended to insulate users from implementation details when we are WRITING client applications, we are most assuredly not so insulated when we are RUNNING shared code in our client applications. The operation of the application strongly depends on the implementation in the shared code. (Why do all Smalltalk programs have the same look and feel?). We are as yet unwilling to completely abrogate control unless the shared code provides something more valuable than control. I still think that sharing of low-level classes faces insurmountable problems that can be stated in economic terms: I won't "buy" your stack or linked list class because it would cost me control and return little benefit (because those are small, easy classes to write myself, and if I write them I understand -control- them). The most successful set of shared classes, the Smalltalk hierarchy, contains small classes, but the corpus is large enough to compensate the loss of control with the ability to rapidly prototype a multitude of interesting client applications. There is nothing better for general-purpose prototyping, but it is not hard to develop something better for any specific application area. Here's a proposal for consideration that takes into account the vague public-spirited desire and critical technical need to share software noted by Dag Bruck while also acknowledging the reality of the notable lack of code postings (other than my fft_server) and the self-consciousness noted by Fraser Orr above: Don't share code. Offer sets of header files. Let interested parties contact you about code if they decide they want it. We might get beyond the self-consciousness and, perhaps, get *moving* on this whole issue of code sharing by SHARING ARCHITECTURES as embodied in related sets of class definitions (our .h files) and letting other folks provide their own implementations. That way we gain the benefits of the experience and expertise of great designers by adopting their clever architectures without abrogating control or adopting an implementation that does not really meet our needs. And we don't expose our tacky code hacks to universal criticism. Publishing architectures for free might actually serve as an advertisement for a body of code that people might in fact "buy" or even $buy$ while providing a public service for those whose needs require some different kind of implementation. Comments are, of course, invited. --------------------------------------------------------------------- Dr. James M. Coggins coggins@cs.unc.edu Computer Science Department Question: "How 'bout them HEELS?" UNC-Chapel Hill correct response: Chapel Hill, NC 27599-3175 "How 'BOUT them Heels?" and NASA Center of Excellence in Space Data and Information Science =============================================================================== In article <7101@thorin.cs.unc.edu> you write: ++ Some time ago I made similar points in the article where I posted my ++ FFT server code. There were no responses and there have been no ++ followups with postings of other interesting classes. My main reason for not posting code and class examples is that I'm not sure if comp.lang.c++ is the proper forum; it seems more oriented to *discussion* of the language. In a similar vein, large source postings are generally discouraged on the already-bloated comp.lang.c. Instead, there are the comp.source.unix, alt.sources, and comp.sources.misc bboards for source submissions. On the other hand, there really hasn't been much of a C++ focus on those bboards. I'd be happy to share some useful, concise, and general-purpose classes, as long as doing so won't piss off the comp.lang.c++ readers. So the open question is: Are code postings relevant to comp.lang.c++? ++ Programming is still very much a private art, not a public practice ++ (tip of the hat to Gerald Weinberg). I appreciate your general point, but must disagree in this case. As far as finding a *large* collection of C++ library code and useful (and well documented) class abstractions, check out the GNU libg++ library, available via ftp from prep.ai.mit.edu. There is a newsgroup, gnu.g++.lib.bug, that offers a potential forum for code sharing and technical discussion, etc. That's one of the big advantages of the GNU project, i.e., it encourages wide-spread sharing of code and design information. And the price is right... ;-) Thanks for raising this issue, Doug -- schmidt@ics.uci.edu (ARPA) | Per me si va nella citta' dolente. office: (714) 856-4043 | Per me si va nell'eterno dolore. | Per me si va tra la perduta gente. | Lasciate ogni speranza o voi ch'entrate. =============================================================================== In article <8688@paris.ics.uci.edu> Doug Schmidt writes: >...As >far as finding a *large* collection of C++ library code and useful >(and well documented) class abstractions, check out the GNU libg++ >library... And the price is right... ;-) The price is not right for many commercial users -- the price is acceptance of the GNU licensing terms. One may argue about the intrinsic rightness of the licensing terms, but the fact is that they're unacceptable to many commercial organizations today. -- The Earth is our mother; | Henry Spencer at U of Toronto Zoology our nine months are up. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu =============================================================================== -- Department of Automatic Control Internet: dag@control.lth.se Lund Institute of Technology P. O. Box 118 Phone: +46 46-108779 S-221 00 Lund, SWEDEN Fax: +46 46-138118