🚀 go-pugleaf

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 <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!
>
>One thing that you should point out is that the code doesn't need to be
>good.

Right, I will make my own linked-list library available.  It is a
re-write of some old Ada code that never compiled because the Ada
compiler was brain damaged.  Can you think of a more disgusting
heritage (:-) ?

I have so far received 10 answers.  C'mon folks!

>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.

This is a good idea.  I will not do it!

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

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

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.

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

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

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