Topic: C++ Class Library Standards
Author: mjv@objects.mv.com (Michael J. Vilot)
Date: 8 Aug 90 05:05:54 GMT Raw View
Chuck Noren asked about the current state of the standardization of class
libraries for C++, and suggested some candidates for inclusion. I have
been working with the folks on the X3J16 committee who are addressing this
issue.
At the first technical meeting in March, the committee set two initial
concerns as priorities for the library efforts:
1) compatibility with the ANSI C library, and
2) stream I/O.
We need to make specific, detailed proposals for anything that is to be
considered for inclusion into the standard. It helps if the proposals are
based on actual implementations.
The discussion between the March and July meetings did cover some suggested
classes for inclusion in the standard, including several of those Chuck
mentioned in his posting. The consensus at the July meeting was that
attempting to develop a comprehensive class library (on the scale of NIHCL,
as Chuck suggested) was far too optimistic for the immediate (2 year)
future.
Something else to consider is that standardizing a large library, while
helpful to those interested in porting their applications, creates a lot of
work for the compiler vendors trying to conform to the standard.
The main problem we face is that there is precious little ``existing
practice'' to standardize in the area of libraries for C++. Paul Chisolm's
comment about the string class is an indication of the problem -- there are
many different opinions of what a ``standard'' class should look like.
Another factor is that the availablity of exceptions and templates will
have a significant impact on the design of C++ class libraries.
Those of you who have built C++ class libraries probably have some
suggestions to make regarding the contents of the library. This seems to
be as good a forum as any for hashing out the issues.
--
Mike Vilot, ObjectWare Inc, Nashua NH
mjv@objects.mv.com (UUCP: ...!decvax!zinn!objects!mjv)
Author: noren@dinl.uucp (Charles Noren)
Date: 3 Aug 90 16:57:44 GMT Raw View
What is being done about establishing official class libraries
for C++? I think a standard that addresses class types of
similar power as the National Institute of Health Class Library
(NIHCL) would be quite useful in developing portable code.
Perhaps significant movement is already being made in class
standards, and what is proper to be considered as standards
associated with C++, but I'll continue with my ignorance and
suggest some "strawman" class libraries I would like to see:
1. General data structures. This would include things
like collections, bags, sets, dictionaries, stacks,
queues, heaps, etc.. Similar to NIHCL.
2. Math class library. This would include matrix operations,
complex numbers, and other mathmatical classes.
3. Operating System class library. This would include
a "process" class (start and kill processes, status
processes),classes that support Inter-Process Communication
(IPC), perhaps file I/O.
4. Database class library (I've heard that there are OODB
standards groups in existance).
5. A windows class library (perhaps similar to InterViews).
6. A 2-D graphics class library. This would support line
graphs, bar charts, pie charts, etc..
7. A 3-D or advanced graphics library.
Some of these class libraries probably don't fall into the
domain of the C++ standards group, but it would be nice to
develop a master plan for class libraries, which would have
obvious advantages. What is being done? What would you like
to see?
--
Chuck Noren
NET: dinl!noren@ncar.ucar.edu
US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260,
Denver, CO 80201-1260
Phone: (303) 971-7930
Author: psrc@mtunq.ATT.COM (Paul S. R. Chisholm)
Date: 5 Aug 90 14:04:05 GMT Raw View
In article <1684@dinl.mmc.UUCP> noren@dinl.UUCP (Charles Noren) writes:
> What is being done about establishing official class libraries for
> C++? I think a standard that addresses class types of similar power
> as the National Institute of Health Class Library (NIHCL) would be
> quite useful in developing portable code.
and suggests such a library should include
> 1. General data structures. This would include things
> like collections, bags, sets, dictionaries, stacks,
> queues, heaps, etc.. Similar to NIHCL.
True enough. However, by the time we have an standard for C++, we
should have a standard for encapsulated data types. For projects that
want to do lots of static type checking, using encapsulated types is
better than using the Smalltalk/NIHlib approach. For projects that
want to do Lisp-like applications, more type freedom at compile time is
handy. The language, and thus, the standardization effort, does and
probably should favor the former class (no pun intended) of users.
> 2. Math class library. This would include matrix operations,
> complex numbers, and other mathmatical classes.
Complex is close to being standard; they're in the AT&T distribution.
Matrices are re-invented often enough that they should be standardized.
Should they do run-time bounds checking? (Probably.) Should arrays
that do run-time bounds checking be part of the standard? (Probably.)
> 3. Operating System class library. This would include
> a "process" class (start and kill processes, status
> processes),classes that support Inter-Process Communication
> (IPC), perhaps file I/O.
File I/O, yes, and almost certainly iostreams. The Task library does
lightweight processes (and has a portable interface, but can't be
implemented portably, which is okay). The semantics of starting a new
process vary drastically from operating system to operating system.
How heavily should the C++ standard rely on POSIX? (Bear in mind that
there are some POSIXisms that break existing UNIX(R) code.)
> 4. Database class library (I've heard that there are OODB
> standards groups in existence).
I worry that they're going to be ready by the time the rest of the
standardization effort is close enough.
> 5. A windows class library (perhaps similar to InterViews).
> 6. A 2-D graphics class library. This would support line
> graphs, bar charts, pie charts, etc..
> 7. A 3-D or advanced graphics library.
Both the portability and timeliness issues are a problem here. Very
little of *any* of the things we've discussed here are "codifications
of current practice", but are of general interest to C++ programmers.
I'm not sure the same can be said of graphics.
> What is being done?
Some people are talking about it in netnews. Ooooh.-)
> What would you like to see?
If we don't *finally* agree on a standard String class, there's gonna
be blood in the streets.-)
>Chuck Noren, Martin Marietta, dinl!noren@ncar.ucar.edu
Paul S. R. Chisholm, AT&T Bell Laboratories
att!mtunq!psrc, psrc@mtunq.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.
UNIX is a registered trademark of UNIX System Laboratories, Inc.,
a subsidiary of AT&T.