newsuser@LTH.Se (LTH network news server) (03/13/89)
Here are the results from the C++ Class Library Survey posted about
two weeks ago. Some interesting comments are available in another
posting.
I must admit I expected more responses, considering the number of
people that apparently work actively with C++. I hope this survey
will spawn an increased interest in sharing C++ code, and that a
survey sometime later this year will give many more replies.
I would like to thank everyone that responded to the survey.
Comments are welcome.
Dag M. Bruck
===============================================================================
Name: gperf
Type: perfect hash function generator
Description: Generates C lookup routines that determine in O(1) time
whether a key is a member of a static search set. Very
useful for reserved word lookups in compiler front-ends.
Machine(s): Any machine with a GNU G++ compiler
Compiler(s): GNU G++ and GNU libg++
Other requirements: (must be GNU G++ version 1.31 or later)
Availability: Available in the libg++ distribution and from FTP 128.195.0.1
Costs money: Subject to the GNU General Public License
Contact: Douglas C. Schmidt <schmidt@ics.uci.edu>
Other comments: Help stamp out software hoarding!
===============================================================================
Name: libg++
Type: class library
Description: The GNU G++ library
Machine(s): Any machine with a GNU G++ compiler
Compiler(s): GNU G++
Costs money: Subject to the GNU General Public License
Contact: Doug Lea (ld@rocky.oswego.edu)
===============================================================================
Name: Symtab
Type: class
Description: Provides a table of name and association pairs
with type information. These can be saved and loaded
from file. They may also be traversed as a list.
If you wished to use it, then you would have to
modify it a little (The type information is very specific
to its original use.)
Machine(s): Sun (but should be widely portable, even off unix)
Compiler(s): Glockenspiel, AT&T
Availability: You can have it if you want it.
Status: A bit messy.
Costs money: public domain
Contact:
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
===============================================================================
Name: Various
Type: library
Description: My personal library of common routines. It includes :
error : exit with an error
Debug_Mesg : print a Debug message if
debugging is on.
Wait_On_User : Pause to let user see screen
wait for a return to be typed.
Soundex : Give the soundex incoding for a string
Blank_Lines : Skip all the blank lines
in input, returning the first non blank one.
Get_Word : Extract the next word from a string
returning also the rest of the string.
Is_Blank_Line : indicate if a line is blank (whitespace only)
Skip_Leading : return pointer to first non whitespace in line.
Split_Into_Words : returns an array of words, that are the
whitespace seperated components
of the given line.
Tidy_Up : Convert a line to cannonical form (no leading white
space, only one space between words)
getstr : internal version of gets that keeps a line number.
Machine(s): Sun (ports easily to others, even off unix)
Status : A bit messy
Costs money: public domain
Contact:
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
Other comments: This library is written in C, with a header file
to interface it to C++
``Here is another not very good qualality piece of software
that you can put in your library.''
===============================================================================
Name: string
Type: class library
Description: Counted strings of static length. Also includes a
character data type.
Full description in Swedish!
Jag har en klass f|r str{ngar. Str{ngarna {r statiska i sin l{ngd (det g}r
enkelt att {ndra s} att de blir dynamiska, men med viss overhead) och
l{ngden lagras i en separat variabel i klassen. Bort med null-terminerade
str{ngar! Jag {r dock inte helt n|jd med klassen. F|r att konvertera till
"vanliga" str{ngar, m}ste man explicit anv{nda en funktion som returnerar
en pekare till en char*. Man m}ste dessutom manuellt g|ra delete p} den
pekaren efter}t.
Machine(s): Encore Multimax/UMAX V
Compiler(s): G++
Other requirements: -
Availability: hack
Costs money: public domain
Contact: Robert Claeson, rclaeson@erbe.se
===============================================================================
Name: COOL
Type: collection of integrated class libraries
Description: class libraries for devices, files, images, and 3-D graphics
plus miscellaneous items such as an FFT server, random variates,
histograms, remote compute server connections, and more.
Machine(s): vax780, sun3, sun4
Compiler(s): I use AT&T Cfront but no Cfront-dependent hacks.
Other requirements: Device classes would need to be modified for a
new environment. Image display requires color Sun3 or Sun4.
Current image display tool uses SunView; X version is planned.
Availability: About to be released through our department's SoftLab
with source code and documentation.
Costs money: nominal fee to cover SoftLab duplication/distribution/
administrative costs only- something like $200 for univ;
$400 for companies is being discussed but not decided.
Technical specs and general info are free from contact below.
Contact: for info/papers/software: softlab@cs.unc.edu
for technical discussion: Dr. James Coggins <coggins@cs.unc.edu>
Mailing address: SoftLab Coordinator
Computer Science Department
University of North Carolina
Chapel Hill, NC 27599-3175
Other comments:
COOL will probably be more widely useful as an example of
an integrated, strictly object-oriented library illustrating
many variations on the themes of encapsulation and inheritance.
We use it for image pattern recognition and computer graphics
research, and it's great for that too, but, I expect, for a smaller
audience. Official release of COOL is scheduled for mid-April 1989.
The distribution will include a tape, a binder with papers and
documentation, and test programs.
===============================================================================
Name: MacApp 2.0
Type: class library
Description: Complete class library for developing Macintosh applications
- includes support for menus, desk accessories, scrolling, resizing
windows, printing, views, undo, cut & paste, etc. It even has
spreadsheet-style and text-editor views. It also has an object inspector
and a built-in debugger which supports browsing objects. It comes with
complete source code. MacApp is written in Object Pascal, but there will
be C++ header files supplied with it, so you can write C++ classes which
inherit from MacApp classes.
Machine(s): Apple Macintosh
Compiler(s): MPW C++, Object Pascal
Other requirements: Macintosh Programmer's Workshop (MPW) 3.0
Availability: real product, in late beta
Costs money: yes, < $1000, including the MPW programming environment +
$100 yearly licence fee for commercial applications.
Contact: Apple Programmers & Developer's Association (APDA),
Apple Computer, Inc., 20525 Mariani Ave., MS: 33-G,
Cupertino, CA 95014-6299,USA
Other comments: This is a very nice toolkit for putting together
Macintosh applications. It has been developed over the last five years,
so it has had more time to mature than most oo-toolkits. Object Pascal is
an extended Pascal which is similar in power to (and inter-operable with) C++.
From: Palevich@apple.com (Jack Palevich)
Organization: Apple Computer, Inc.
===============================================================================
Name: ACL (A Class Library)
Type: class library
Description: A wide variety of classes. Includes lists, stacks,
queues (priority, fifo), hashtables, symbol tables, unix
ioctl interface, memory management, error logging and handling,
network interface (stream sockets, distributed processing)
Machine(s): Sun 3
Compiler(s): AT&T 1.1
Other requirements: Unix (BSD or with BSD extensions)
Availability: pretty stable hack
Costs money: no
Contact: Jim Nusbaum
LLUMC Radiation Research Laboratory
(714) 824-4077
proton!nusbaum@ucrmath.ucr.edu
Other comments: My Masters project. Constructed in 1987 as a demonstration
of the powers of object oriented implementation methods. This
library was well tested and documented and made extensive use of
many C++ features for both efficiency and generality.
Full users manual in LaTex form, well commented code.
===============================================================================
Name: ClassKit(tm)
Type: class library and development tool
Description: a complete application framework that will support user
interface development, printing, persistent objects, collection classes,
b-tree indexing, and more. Will provide development and debugging tools
including inspectors, browsers, and more.
Machine(s): Macintosh initially
Compiler(s): MPW C++ and C initially
Other requirements: Knowledge of Macintosh programming
Availability: real product under development
Costs money: yes
Contacts: Mark Richer, Mountain Lake Software, Inc.,
415-752-6515 AppleLink: D1036
Or "richer@sumex-aim.stanford. edu" or Nick Pilch "Nicky@cup.portal.com"
Other comments: We will be demonstating ClassKit at
MacWorld, Boston, August 1989.
===============================================================================
Type: class library/development tool
Description: Defines arithmetic types for variables residing on a
Connection Machine, including int, unsigned int, and float. It is
implemented in C++/Paris for 5.0 Paris. It facilitates programming
the Connection Machine from a C environment (and avoids C*). C++
expressions can be passed to Paris calls interspersed in the user code.
Simple memory management is provided.
Machine(s): Vax (tested) Sun (untested)
Compiler(s): G++
Other requirements: CM-2, relase 5.0 of CM software, C/Paris interface
files (paris.h, cmtypes.h, etc.).
Availability: hack/under development
Costs money: not public domain
Contact: rjc@cs.ucla.edu (Robert Collins)
===============================================================================
Name: CommonView
Type: class library for user interface
Description: C++ User Interface - OS/2 PM, MS Windows and X Windows Drivers
Machine(s): ?
Compiler(s): ?
Other requirements:
Availability: available
Costs money: yes
Contact: OASys +1 617 890-7889
===============================================================================
Name: `new' using shared heap
Type: other
Description:
Alternate _new and _delete using space off a shared data segment,
so that data structures are shared between a community of programs.
Faster than the original (that use native 'malloc' and 'free'),
but the main intent is to eliminate data transfer overhead
among a suite of (separately developed) applications
operating on a common set of large objects.
Machine(s): i80386
Compiler(s): Xenix CC, Oasys/Glockenspiel Designer C++
Other requirements:
Availability: proprietary
Costs money: not distributed
Contact: Brad Fowlow
Bell-Northern Research
...!mcvax!mcgill-vision!bnrmtl!brad
brad%bnrmtl.UUCP
Questions/discussion invited.
We've also got a full suite of self-gc'ing object/collection classes.
All is part of window graphics system (in C++) built on GKS.
===============================================================================
Type: class library
Description:
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.
Machine(s): ?
Compiler(s): ?
Contact: jima@hplsla.HP.COM (Jim Adcock)
HP Lake Stevens, WA
===============================================================================
Name: NIH Class Library (used to be called OOPS)
Type: class library
Description: Portable selection of classes similar to those of
Smalltalk-80. Contains strings, date, time, collection
classes (indexed arrays), linked lists, hash tables,
associative arrays, object i/o, and coroutines.
Machine(s): ?
Compiler(s): AT&T C++ Translator, release 1.2.1
(will require an AT&T R2.0 compatible compiler)
Availability: ?
Costs money: ?
Contact: Keith Gorlen, National Institutes of Health
keith@alw.nih.gov
uunet!nih-csl!keith
===============================================================================
Name: Kernel
Type: class library
Description: Co-routine package, including semaphores, events and the
basics for writing monitors. Has pre-emptive scheduling
to enable addition of external interrupts.
Machine(s): Sun, Silicon Graphics, ...
Compiler(s): AT&T 1.2.1 (easily ported)
Other requirements: none
Availability: By E-mail
Costs money: no
Contact:Dag Bruck
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
===============================================================================
Name: List
Type: class library
Description: Linked lists with the usual operations.
Machine(s): Sun, Silicon Graphics, ...
Compiler(s): AT&T 1.2.1 (easily ported)
Other requirements: none
Availability: By E-mail
Costs money: no
Contact:Dag Bruck
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
===============================================================================
Name: Cynergy
Type: Development environment
Description: The environment itself is written in Smalltalk running as
a process under Unix; the compiler is an OEM version of the
Glockenspiel compiler, talking to the environment via UNIX IPC.
Therefore the system will run on the set of platforms which is the
intersection of the sets supported by PPS Smalltalk and Glockenspiel:
Sun 3 for first release.
The environment includes a code browser, a debugger, dependency
control for recompilation and linking, and an incremental linker. All
the user interface code and the symbolic side of the debugger run as
Smalltalk code in the Smalltalk image; the C++ source code also
resides there (it is kept in memory during a user session).
Contact: Jeannine Femia in Marketing at (415) 859-1051.
Other comments: This information was posted in comp.lang.c++ by
Bruce Cohen
Interactive Technologies Division, Tektronix, Inc.
M/S 61-028, P.O. Box 1000, Wilsonville, OR 97070
brucec@orca.wv.tek.com
===============================================================================
--
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-138118newsuser@LTH.Se (LTH network news server) (03/13/89)
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 <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 =============================================================================== -- 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