rfg@lupine.ncd.com (Ron Guilmette) (08/01/90)
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.
chip@tct.uucp (Chip Salzenberg) (08/17/90)
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
mjv@objects.mv.com (Michael J. Vilot) (08/18/90)
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)
rfg@NCD.COM (Ron Guilmette) (08/18/90)
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.
bright@Data-IO.COM (Walter Bright) (08/21/90)
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.mjv@objects.mv.com (Michael J. Vilot) (08/21/90)
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)