Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!pacbell!att!dptg!mtunq!psrc
From: psrc@mtunq.ATT.COM (Paul S. R. Chisholm)
Newsgroups: comp.std.c++
Subject: Re: C++ Class Library Standards
Summary: NIHlib is nice, but parameterized types may be nicer (maybe)
Message-ID: <1205@mtunq.ATT.COM>
Date: 5 Aug 90 14:04:05 GMT
References: <1684@dinl.mmc.UUCP>
Organization: AT&T Bell Laboratories
Lines: 72

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.