Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!deccrl!decvax.dec.com!zinn!nuucp
From: mjv@objects.mv.com (Michael J. Vilot)
Newsgroups: comp.std.c++
Subject: Re: Questions on the evolving standard.
Message-ID: <873@zinn.MV.COM>
Date: 21 Aug 90 01:39:53 GMT
Sender: nuucp@zinn.MV.COM
Lines: 61

Ron Guilmette asks:
> When you say `compatibility with THE C LIBRARY' I'm left wondering.

Sorry for the lack of precision.  The ANSI C standard is one of the two
base documents for the ANSI C++ standard.  It contains a Library
specification (Chapter 4).
  Since there's a lot of interest in providing mixed ANSI C/ANSI C++
implementations, that's the library that an ANSI C++ standard must be
``compatible'' with.  I would expect other standards (notably POSIX) to
develop separate `C++ bindings' as interest develops -- it's beyond the
scope of X3J16 to formulate these.

> What about the types for arguments ... ?
> What about error conditions ... ?

These are important questions to answer.  The availability of exceptions in
ANSI C++ (if and when ...) will certainly impact the design considerations
of any library.
  Steve Clamage (steve@taumet.com) and Shawn Nash (nash@s55.prime.com) are
collecting ideas and formulating a proposal for November's meeting which
will address these issues for the ANSI C library.  I'm sure they would
welcome any suggestions you have.
  I'm particularly interested in hearing what chances you think we have of
modifying the ANSI C standard to improve the library's type safety.

> What about groups of functions that operate on particular types ... ?

Your example, which looks a lot like the class `File' from libg++, is one
of the ways an ANSI C++ library could offer a better solution to the set of
facilities provided by the ANSI C library.  Personally, I would like to see
us do something useful and effective along these lines.

However, there is some concern over (needlessly ?) duplicating equivalent
functionality (even for the sake of type safety and user extensibility).
  There is also (apparently) a significant number of people interested in
being able to switch to a C++ compiler and rebuild their existing C code
without any changes to their source files.

  I think this implies that any `extern "C"' linkage specifications will
have to be part of a vendor's set of header files, rather than required to
be part of user code.  That is, I would not expect to see:
	extern "C" {
	#include <stdlib.h>
	}
in users' C++ source files, but rather:
	#ifdef __cplusplus
	extern "C" {
	#endif
	...
	#ifdef __cplusplus
	}
	#endif 
(or something equivalent) in a file `stdlib.h' supplied as part of a
vendor's mixed C/C++ environment.

If this is the preferred approach, I doubt there's much hope of changing
the ANSI library to a significant degree.

--
Mike Vilot,  ObjectWare Inc, Nashua NH
mjv@objects.mv.com  (UUCP:  ...!decvax!zinn!objects!mjv)