home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 January
/
usenetsourcesnewsgroupsinfomagicjanuary1994.iso
/
sources
/
std_unix
/
v21
/
174.a.diff
< prev
next >
Wrap
Text File
|
1990-12-05
|
17KB
|
392 lines
389 vn/174 vn/174.a
1c1
< From jsq@cs.utexas.edu Wed Oct 3 11:08:06 1990
---
> From std-unix-request@uunet.uu.net Wed Oct 3 11:21:46 1990
3,4c3,4
< id AA14297; Wed, 3 Oct 90 11:08:06 -0400
< Posted-Date: 3 Oct 90 15:46:12 GMT
---
> id AA18463; Wed, 3 Oct 90 11:21:46 -0400
> Posted-Date: 3 Oct 90 14:58:36 GMT
6c6
< From: jason@cnd.hp.com (Jason Zions)
---
> From: jsh@usenix.org (Jeffrey S. Haemer)
8,14c8,10
< Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
< Message-Id: <13142@cs.utexas.edu>
< Sender: jsq@cs.utexas.edu
< Organization: Hewlett Packard, Information Networks Group
< Subject-References: <13132@cs.utexas.edu> <13135@cs.utexas.edu>
< X-Submissions: std-unix@uunet.uu.net
< Date: 3 Oct 90 15:46:12 GMT
---
> Subject: Standards Update, X3J16: C++
> Message-Id: <571@usenix.ORG>
> Sender: jsq@usenix.ORG
15a12,14
> Organization: USENIX Standards Watchdog Committee
> X-Submissions: std-unix@uunet.uu.net
> Date: 3 Oct 90 14:58:36 GMT
18c17
< Submitted-by: jason@cnd.hp.com (Jason Zions)
---
> Submitted-by: jsh@usenix.org (Jeffrey S. Haemer)
20c19
< Dominic Dunlop says:
---
> An Update on UNIX1-Related Standards Activities
22,28c21
< > I dare say that, as more types of object appear in filename space (and
< > I, for one, should like to see them do so), the question of determining
< > uniqueness will become knottier. Suppose, for example, that one used
< > filenames as handles for virtual circuits across a wide-area network.
< > Conceivably, the number of such circuits could be sufficiently large
< > that it will become difficult o shoe-horn a unique identifier into the
< > existing stat structure fields. A problem for the future?
---
> October 3, 1990
30,40c23
< Actually, a problem for today. P1003.8 has to cope with the fact that a
< local file for major 0, minor 0x010100, inode 1234 is *different* from a
< file on some remote machine with the same (major,minor,inode) triplet. But
< adding a new field or fields to the stat structure isn't gonna work;
< expanding that structure will cause many implementations to shatter (i.e.
< break spectacularly). Just cobbling up a major number for some random
< remotely-mounted filesystem is unsatisfactory, unless the cobble is
< persistant over umount/mount operations. (An application starts to run;
< opens file1 on remsys, gets (maj,min,ino). Network goes down, comes up;
< system remounts remsys. App opens file2 on remsys. That major number had
< better be the same for remsys!)
---
> USENIX Standards Watchdog Committee
42,48c25
< What's needed is a simple routine which can be called to determine if two
< handles point to the same object. It would be nice if there was a routine
< which took as arguments a file handle and a path name and returned true iff
< the path referred to the same file. This routine would be guaranteed by the
< implementor to work for any file-system resident object provided for; e.g.
< an SVR4 implementation would have to be able to tell if a file opened via
< RFS referred to the same underlying file as one opened under NFS.
---
> Jeffrey S. Haemer <jsh@usenix.org>, Report Editor
50,53c27
< I don't know if that's sufficient, though; application programmers may be
< using the stat info for other purposes, and a remote_addr field might be a
< good idea. Once P1003.12 decides on a representation for an arbitrary
< network address, which might be considerably larger than an IP address.
---
> X3J16: C++
55c29,336
< Jason Zions
---
> Mike Vilot <mjv@objects.mv.com> reports on the July meeting in
> Seattle, Washington:
>
> Standard C++?
>
> The C++ programming language has been gaining popularity at a
> remarkable rate (an informal estimate is that the C++ population
> doubles every nine months). One reaction to the growing popularity
> has been a call to stabilize the language's definition, and achieve
> some consistency across implementations. C++ is popular enough that
> larger corporations are considering adopting it as an officially
> endorsed development language -- but some cannot make such a move
> unless the language is defined by a standard.
>
> For these and other reasons, the ANSI secretariat agreed to establish
> the X3J16 committee to formulate a standard for C++. Dmitry Lenkov,
> of HP, made the official proposal, and serves as chairman of the
> committee. To date, X3J16 has met three times: an organizational
> meeting last December, the first technical meeting in March to get
> organized, and a meeting in July to really get started.
>
> The December meeting, in Washington D.C., was purely administrative:
> over 50 attendees received lectures and tons of paper on X3 rules and
> procedures. The highlight of the day was an invited presentation by
> Bjarne Stroustrup on ``the spirit of C++.'' The transcript is
> available as committee document X3J16/90-0022 or from Greg Comeau at
> Comeau Computing, 91-34 120th Street, Richmond Hill, NY 11418, (718)
> 849-2355.
>
> March meeting
>
> AT&T hosted the meeting in New Jersey. Most of the week was spent on
> administrative matters, while the group got organized and accustomed
> to The Bureaucratic Way. Since most of the members are engineers, the
> highlight of the week was the evening technical sessions on
> implementing exception handling for C++. (The week was sort of a
>
> __________
>
> 1. UNIXTM is a Registered Trademark of UNIX System Laboratories in
> the United States and other countries.
>
> October 3, 1990 Standards Update X3J16: C++
>
>
> - 2 -
>
> mini-Usenix conference, as most members had gone without a substantial
> C++ gathering since the October '88, Denver conference.)
>
> The week's major activities were discussing and preparing a goals
> document, describing the committee's activities and priorities.
>
> Goals
>
> Here is a brief outline of the goals document, which is available as
> X3J16/90-0023:
>
> 1. Base documents: C++ Reference Manual, ANSI C (ANS X3.159-1989),
> ISO C when available.
>
> 2. Standardize syntax and semantics of the language as a token
> sequence without the presence of preprocessing directives.
>
> 3. Define and standardize a minimum set of C++ libraries, their
> contents, and interfaces.
>
> 4. Standardize elements of a C++ environment.
>
> 5. Consider proposed major changes: parameterized types and
> exceptions.
>
> 6. Ensure that the standard is suitable for the international
> community.
>
> 7. Ensure a very high level of compatibility with ANSI C.
>
> 8. Establish coordinating liaisons with X3J11 (ANSI C) and
> Numerical C Extensions Group.
>
> 9. Produce two deliverables: draft proposed standard and rationale.
>
> 10. Priorities:
>
> - clear & unambiguous
>
> - C++ reference manual
>
> - other base documents
>
> - consistency
>
> - user/implementer experience
>
> - portability, efficiency, expressiveness
>
> - ease of implementation (including translation to C)
>
> October 3, 1990 Standards Update X3J16: C++
>
>
> - 3 -
>
> There was some confusion over the multiple base documents. Most
> members had seen the AT&TT C++ version 2.0 reference manual, but in
> preparation for standardization, the language and its reference manual
> had suffered a number of subsequent, small changes. AT&T made the 2.1
> reference manual available to X3J16; it was essentially the text of
> the book The Annotated C++ Reference Manual by Margaret Ellis and
> Bjarne Stroustrup published by Addison-Wesley (minus the annotations).
>
> My naive suggestion to remove the ANSI C standard as a base document
> in favor of a single base provoked the most intense and emotional
> discussion of the week. At stake was compatibility between C++ and C.
>
> While most members of X3J16 feel that the existence of a separate
> committee implies the standardization of a new language, some former
> members of X3J11, which just finished the C standard, want to
> eliminate any and all incompatibilities with C. (There was even a
> threat to sabotage the C++ standard in balloting if they are not
> removed.)
>
> This issue is obviously important and has two sides. Make your
> preferences known to the committee. For detailed reference material,
> both ``C++: As Close as Possible to C -- But No Closer,'' (Bjarne
> Stroustrup and Andy Koenig, The C++ Report, 1(7), 1989) and Chapter 18
> of The Annotated C++ Reference Manual document and explain differences
> and incompatibilities between the languages as they stand today.
>
> Focusing on a language without preprocessing directives continues the
> de-emphasis of the C preprocessor. This is particularly favored by
> C++ vendors looking into more powerful development environments.
> [Editor: Admittedly, improper preprocessor use can sink us in deep and
> dirty bath water, but let's make sure to save the baby. When writing
> portable C, I personally find #ifdefs extremely valuable; I suspect
> they will remain valuable in C++, and I would hate to see the working
> group neglect this valuable porting tool.]
>
> The libraries effort includes asking what to do about the ANSI-C
> library, and investigating what can be standardized in a more C++-like
> approach.
>
> The environment work addresses the linking and executing of C++ code
> with non-C++ code (i.e., linkage and program execution models), rather
> than development environment tools.
>
> There are thousands of suggested ``improvements'' proposed as
> extensions to C++, but there is consensus on two named in the goals
> document: parameterized types and exception handling. Their proposals
> are detailed, and both have been implemented (in some form) in a few
> C++ implementations.
>
> The emphasis on international concerns reflects the lessons learned
> from the difficulties of C standardization. X3J16 has some fences to
>
> October 3, 1990 Standards Update X3J16: C++
>
>
> - 4 -
>
> mend, particularly in the international community. Rather than
> waiting until the last minute to spring a standard on the ISO, the C++
> committee is involving itself with the international community right
> from the start.
>
> July meeting
>
> Microsoft hosted the second, Seattle meeting. Sub-groups focused on
> the key topics listed in the goals statement began work at the March
> meeting, and reported their progress in Seattle.
>
> International Concerns
> Steve Carter, of Bellcore, presented the major International
> Concerns (particularly character sets and formal specification)
> and asked the other groups to work on these issues. He also
> suggested various sites overseas where future X3J16 meetings
> could help cooperation with international standardization
> efforts.
>
> Editorial
> Jonathan Shopirio, of AT&T, presented the Editorial group's
> proposal for organizing and formatting the standard. Jon is also
> working on an abstract machine model, and a way to define the
> semantics in the standard precisely and consistently.
>
> Formal Syntax
> James Roskind, an independent consultant, presented the work of
> the Formal Syntax group. He has developed (and published on the
> net) a yacc-able grammar for C++, and is concerned about
> ambiguities in the the language. Most of the discussion was
> spent trying to discover whether C++ can (or should) be made
> LALR(1).
>
> Core Language
> Andy Koenig, of AT&T, presented the Core Language group's work.
> Initially, they identified and classified difficulties in the
> working document.
>
> Environment
> John Vasta, of HP, presented the work of the Environment group.
> A key issue addressed by this group is the interaction of C++
> with other programming languages. Among the important topics are
> linkage of C++ and non-C++ translation units, especially the
> construction and destruction of static C++ objects.
>
> Libraries
> I presented the Library group's work. There were many
> suggestions, from both inside and outside of the committee.
> (Interested outside suggesters were James Coggins, Keith Gorlen,
> and Doug Lea, who have each developed large C++ libraries.) A few
> people noted similarity with topics covered by other standards
>
> October 3, 1990 Standards Update X3J16: C++
>
>
> - 5 -
>
> (notably POSIX). Initially, the library group will focus on a
> few commonly-used components. Parameterized types and exception
> handling will significantly effect the way we design libraries in
> C++.
>
> Language Extensions
> Bjarne Stroustrup, of AT&T, presented the work of the Extensions
> group, which was by far the most active. The technical sessions
> presented experience with implementation and use of the template
> facility.
>
> The most active and emotional debate of the week was on exception
> handling, discussing the proposal outlined by Andy Koenig and
> Bjarne Stroustrup in their paper ``Exception Handling for C++''
> presented at the Usenix C++ conference in April. Martin
> O'Riordan, of Microsoft, and Mike Miller, of Glockenspiel,
> presented arguments in favor of extending the current proposal
> (which defines termination semantics for exceptions) to include
> resumption semantics. Andy and Bjarne explained their reasons
> for not including resumption -- the most important was the
> complexity and cost of implementation.
>
> To their credit, the group worked hard to find a proposal that
> provided both kinds of exceptions with acceptably small
> time/space overhead. However, at the end of the week, Bjarne
> declared the debate deadlocked, and refused to impose his
> proposal while substantial disagreement remained. This is
> another topic where you should make your opinions heard.
>
> C Compatibility
> Mike Miller presented the work of the C Compatibility group. Tom
> Plum, of Plum-Hall, produced a list of every section of the C++
> reference manual that was not C. Much of the group's near-term
> activity will be devoted to explaining the many items on the
> list.
>
> The Seattle meeting produced tangible progress on the language
> standard. X3J16 voted to accept the proposed document outline and
> format. They also agreed to incorporate the template proposal (the
> text from Chapter 14 of The Annotated Reference Manual, minus the
> annotations -- it was literally a scissors-and-tape job). We hope C++
> vendors will regard templates as now officially in the language, and
> provide users an opportunity to work with this feature.
>
> Next events
>
> A few substantial issues lie ahead. The next meeting should see some
> resolution on the exception proposal. We should see some progress on
> the review of language ambiguities and inconsistencies, and have some
> idea of how difficult it will be to ANSIfy the document. We should
> also see some specific proposals on library contents. The most
>
> October 3, 1990 Standards Update X3J16: C++
>
>
> - 6 -
>
> substantial will be a simplified version of iostreams by Jerry Schwarz
> (now at Stardent, formerly at AT&T).
>
> Our target date for delivering a draft standard is the end of 1992.
> X3J16 meets three times per year. The next three meetings (and their
> hosts) will be:
>
> + November 12-26, Cupertino CA (Hewlett Packard)
>
> + March 11-15, Nashua NH (Digital)
>
> + June 17-21, Lund Sweden (Lund Institute of Technology)
>
> Membership on an X3 committee is open to any individual or
> organization with expertise and material interest in the topic
> addressed by the committee. The cost for membership is $250. Contact
> the chair or vice chair for details.
>
> Chair: Dmitry Lenkov
> HP California Language Lab
> 19447 Pruneridge Avenue MS 47 LE
> Cupertino, CA 95014
> (408)447-5279
> FAX (408)447-4924
> email dmitry%hpda@hplabs.hp.com
>
> Vice Chair: William M. Miller
> Glockenspiel, Ltd
> P.O. Box 366
> Sudbury, MA 01776-0003
> (508)443-5779
> email wmmiller@cup.portal.com
>
> October 3, 1990 Standards Update X3J16: C++