keffer@blake.acs.washington.edu (Thomas Keffer) (07/21/89)
In article <53@eileen.mga.com> sacco@eileen.mga.com (Joseph E. Sacco)
offered a succinct summary of the jam that we are in: we'd like to use
g++, but the FSF libraries, with their "copyleft", cannot be used for
commercial purposes. We could live with this if each of us wrote our
own library (groan!). The problem with this approach is that we don't
know exactly what to write. Each person has a different idea about
the syntax and symantics of key objects and functions.
AT&T MUST take the lead in getting us out of this developing mess!
It's their language; they should finish the job and define the syntax
and semantics for a few key classes. No one expects "scanf()" to vary
much, why can't we count on well defined properties for:
istream
ostream
complex
slist
olink
math functions (pretty good shape because of similarity to "C")
malloc functions ( " " )
string functions ( " " )
These are really basic classes! We're not asking for garbage
collection here :-)! We should be able to #include <stream.h> and/or
<complex.h> and know what to expect. I am not enthusiastic about
writing my own stream class, but I am willing to do it IF I can be
sure that it will fit in with what my user expects. I don't want to
make them use MY stream class when they use my classes, someone else's
stream class when they use someone else's classes.
What if this chaos existed in the "C" world? Vendor of subroutine
package A would expect the user to call
fprintf(stdout, "Some comment");
while vendor B expects
fprintf(&stdout, "Some comment");
and maybe vendor C would expect
tom_and_dicks_fprintf(Pointer_to_a_secret_struct, "Some comment");
with maybe a flush(stdout) thrown in. In theory, they all can be made
to work, but what a headache!
In this sense, the SEMANTICS of these key classes are indeed "part of
the language". AT&T need not make their libraries (or header files)
public domain, but they must make their syntax and semantics clear.