Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!uakari.primate.wisc.edu!aplcen!uunet!lupine!lupine.ncd.com
From: rfg@lupine.ncd.com (Ron Guilmette)
Newsgroups: comp.std.c++
Subject: Questions on the evolving standard.
Message-ID: <1034@lupine.NCD.COM>
Date: 1 Aug 90 02:48:33 GMT
Sender: rfg@NCD.COM
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 63

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.