Ron Guilmette (after a brief hiatus while he changed jobs) asks:
> The biggest thing that seems to be left unspecified in
> E&S is the whole subject of standard libraries and header files. Are
> there any?
Welcome back, Ron.

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.

We've had a fun time discussing the hundreds of things that might be in
that library.  James Coggins, Keith Gorlen, Doug Lea, and others have
contributed some good ideas.  We've also been reminded that there is only
so much time available, and only so much we can mandate in a standard that
all vendors claiming compliance have to implement.

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

We're trying to get some specific proposals on the first three by the
November meeting in San Francisco.  Jerry Schwarz is working on a
simplified version of iostreams as a basis for the streams discussions.

The easy part seems to be suggesting classes and sketching out the basic
functionality of them.  The hard part is working out the details.  We have
some difficult issues in getting mixed-vendor C and C++ implementations
working together, and a challenging name space management problem (both
with file names and global names) when combining C and C++ libraries.

We could use a healthy discussion here, especially from those of you who
have successfully coped with these issues.


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

According to rfg@lupine.ncd.com (Ron Guilmette):
>One final note.  The biggest thing that seems to be left unspecified in
>E&S is the whole subject of standard libraries and header files.  Are
>there any?  Are the libraries and header files mandated by the ANSI C
>standard considered a part of "standard" C++?

I would also like to know whether I can include <stdlib.h> with
impunity or if 'extern "C"' is supposed to be required.  I made a
local change to our G++ compiler which assumes that all files in
/usr/include are 'extern "C"', so that I can do a simple #include
<stdlib.h> from C and C++ programs.  I would like to know whether a
C++ must, or even may, legally allow such usage.

I also encourage any X3J16 members to speak up on the current status
of the header file and library issues.
--
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
 "Most of my code is written by myself.  That is why so little gets done."
                 -- Herman "HLLs will never fly" Rubin

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.

In article <26CC1668.5785@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
<I would also like to know whether I can include <stdlib.h> with
<impunity or if 'extern "C"' is supposed to be required.

With Zortech C++, all supplied C header files will work equally well with
C and C++ without needing an extern "C" wrapper.

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)

I just want to say that now that this newsgroup has been established (finally)
I would hate to see it fill up with nothing but a load full of semi- good
pet ideas that everybody and his brother has been harboring for ages now
regarding ways to "improve" the language by tweeking this or tweeking that.

I have a couple of such ideas myself, but I'm going to try to restrain
myself from promoting to many of them here.

I'm not saying that such proposals are in any way unsuitable for this group.
NO! NO!  It's just that I'm hoping to *also* see discussions of the many
things which have simply gone unspecified in the official ANSI base documents.

There are (I feel) a lot of unspecified things in the current language
definition, and I really feel that we should be filling the cracks in the
foundation  every bit as much as we should be debating the details of the
design of the upper floors.

I'd now like to mention three examples of things that E&S seem to leave
unspecified.

First, is it legal for a compilation unit to contain zero file-scope
declarations?

Is a "null declarative" statement (i.e. just a lone semicolon) allowed
at the file-scope level?

Section 13.2 (Argument Matching) in E&S (pages 318 & 319) defines a
number of cases in which one particular implicit conversion (or
sequence of implicit conversions) are deemed "better" that some
other particular sequence.  Unfortunately, there is never any
"quantification" of exactly how much better each kind of conversion
is so that arbitrary possibilities for implicit conversion sequences
can be fully and precisely judged against one another.

For example, 13.2 says that converting a `T*' to a `const T*' is worse than
converting (or actually, not converting) a `T*' to a `T*'.  A little later,
it says that if C is derived (publically) from B and if B is derived
(publically) from A, then converting a C* to a B* is "better" than converting
to an A*.  But exactly how much better is it?

This question could become significant in contexts involving multiple
possible sequences of implicit conversions.  It's entirely possible
that there could be a case in which there existed two possible
sequences of implicit conversions, both of which rank otherwise as
equal, except that one involves a conversion from a T* to a const T*
and a conversion from a C* to a B* and the other one involves
a conversion from a C* to an A*.  Which conversion (if either) would be
"better matching"?

The three unspecified things mentioned above are admitedly minor points,
but they need to be addressed in the final standard document.  Also,
I think that implementors would benefit by seeing such things discussed here.

One final note.  The biggest thing that seems to be left unspecified in
E&S is the whole subject of standard libraries and header files.  Are
there any?  Are the libraries and header files mandated by the ANSI C
standard considered a part of "standard" C++?  How about the libraries
and header files called for in Bjarne's original book (e.g. <stream.h>)?

I imagine that the issue of libraries has already surfaced (and perhaps
even been resolved) in the x3j16 meetings.  Perhaps one of the x3j16
members could be encouraged to give us a short progress report based
on the most recent meeting.