noren@dinl.uucp (Charles Noren) (08/03/90)
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-7930psrc@mtunq.ATT.COM (Paul S. R. Chisholm) (08/05/90)
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.
mjv@objects.mv.com (Michael J. Vilot) (08/08/90)
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)