coggins@coggins.cs.unc.edu (Dr. James Coggins) (03/04/89)
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 ---------------------------------------------------------------------
schmidt@siam.ics.uci.edu (Doug Schmidt) (03/06/89)
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.
henry@utzoo.uucp (Henry Spencer) (03/07/89)
In article <8688@paris.ics.uci.edu> Doug Schmidt <schmidt@siam.ics.uci.edu> 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
rae@geac.uucp (Reid Ellis) (03/07/89)
Doug Schmidt <schmidt@siam.ics.uci.edu> writes: |My main reason for not posting code and class examples is that I'm not |sure if comp.lang.c++ is the proper forum; |... |Instead, there are the ... comp.sources.misc bboards for source |submissions. Indeed, I just got a C++ class [lookup] posted to comp.sources.misc. Not very astounding, really, but it's something. I would suggest that C++ source be posted to comp.sources.misc, since it's definitely within bounds for that group. After all, you see anything from C code to sed scripts there. Reid --- rae@geac.uucp (Reid Ellis) 176 Brookbanks Dr, Don Mills ON, Canada, M3A 2T5, +1 416 446-1644 Copyright 1989 Reid Ellis; you may redistribute only if your recipients may.
jima@hplsla.HP.COM (Jim Adcock) (03/08/89)
I would put in a vote for any small postings of code that fill pretty wide spread needs. Try posting some small stuff that you think is good, and see if people like it, or not.
jima@hplsla.HP.COM (Jim Adcock) (03/08/89)
I have a pretty complete set of bit manipulation classes that may be of interest to to hardware driver writers, etc, if anyone is interested. Somewhat too large to post here.
seeger@poe.ufnet.ufl.edu (F. L. Charles Seeger III) (03/09/89)
In article <3748@geaclib.UUCP> rae@geac.uucp (Reid Ellis) writes: |Doug Schmidt <schmidt@siam.ics.uci.edu> writes: ||My main reason for not posting code and class examples is that I'm not ||sure if comp.lang.c++ is the proper forum; ||... ||Instead, there are the ... comp.sources.misc bboards for source ||submissions. | |Indeed, I just got a C++ class [lookup] posted to comp.sources.misc. | |I would suggest that C++ source be posted to comp.sources.misc, c.s.misc may be the best place now. How long before we start discussing c.s.c++? Given the nature of the language, this group will be largely supporting the distribution of classes, rather than entire programs. It needs to be archived somewhere. Further, actual class design could be carried out in this group, perhaps with mailing lists for the persons working on various classes. This would take advantage of ADT nature of the language, while providing public design examples. -- Charles Seeger 216 Larsen Hall +1 904 392 8935 Electrical Engineering University of Florida seeger@iec.ufl.edu Gainesville, FL 32611
campbell@redsox.UUCP (Larry Campbell) (03/09/89)
Sharing classes, in the sense of making classes available that are nearly universally useful, will be very difficult until exception handling is in the language and some sort of convention as to how to use the feature has been widely adopted. The problem is that classes need to report errors. Writing to standard output or standard error is *not* an acceptable way to report errors. (Think of background tasks without stdout or stdout; think of operating systems besides UNIX; think of real-time or embedded or distributed systems.) Pining for cfront v2.0 (any rumors about release dates?)... -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146
campbell@redsox.UUCP (Larry Campbell) (03/09/89)
In article <599@redsox.UUCP> campbell@redsox.UUCP (Larry Campbell) writes: }... }(Think of background tasks without stdout or stdout; think of operating ^^^^^^ oops, of course I meant stderr; that's what comes from posting before the morning's first cup of coffee. -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146
jima@hplsla.HP.COM (Jim Adcock) (03/28/89)
I'll post a copy of my bit manipulation classes to comp.sources.misc