Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!uunet!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.std.c++
Subject: Re: Questions on the evolving standard.
Message-ID: <1239@lupine.NCD.COM>
Date: 18 Aug 90 16:37:10 GMT
References: <866@zinn.MV.COM>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 47

In article <866@zinn.MV.COM> mjv@objects.mv.com (Michael J. Vilot) writes:
>
>The X3J16 committee has set up several working groups to address the
>various aspects of the standard.  The standard will contain a library
>chapter, and there is a working group addressing the library's contents.
...
>So, our focus is on the classes that ``everyone agrees'' will be widely
>used and generally helpful.  An initial classification is:
>
>	1.  C++ language support (new.h, etc.)
>	2.  compatibility with the C library
>	3.  streams
>	4.  everything else

When you say `compatability with THE C LIBRARY' I'm left wondering.  Which
C library?  POSIX?

Regarless of which C library we are talking about, several additional
questions arise:

	What about the types for arguments which are pointers?  Many of
	these could (in theory) be declared as pointer-to-const.  Will
	they be?

	What about error conditions in C library functions?  Are we gonna
	stick with NULL or -1 return values and errno, or will there
	perhaps be `shells' around the C library functions which could
	return such error indicators such that these shells turn errno
	values into raised exceptions?

	What about groups of functions that operate on particular types
	of objects?  Will these end up getting `objectified'?  For example:

		class DIR {
			// ...
		public:
			opendir (...);
			closedir (...);
			readdir (...);
			telldir (...);
			//...
		};
-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.