home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0022.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  9.4 KB  |  304 lines

  1. Submitted-by: pc@hillside.co.uk (Peter Collinson)
  2.  
  3. USENIX Standards Watchdog Committee
  4. Stephen R. Walli <stephe@usenix.org>, Report Editor
  5. Report on X3J16: C++
  6.  
  7.  
  8. Mike Vilot <mjv@objects.mv.com> reports on the March, 1991 meeting in
  9. Nashua, New Hampshire:
  10.  
  11. Current Status
  12.  
  13. The ANSI X3J16 committee began its second year of technical meetings.
  14. As expected, the work grew more detailed, with the Core Language and
  15. Environment working groups being the focus of most of X3J16's work.
  16.  
  17. March meeting
  18.  
  19. Digital Equipment hosted the Nashua meeting.  The week's major
  20. activities focused on understanding the myriad details of the proposed
  21. clarifications and changes to the current working document.
  22.  
  23. X3J16's sub-groups focused on the key topics listed in the goals
  24. statement developed at the March, 1990 meeting.  They worked by
  25. electronic mail between meetings, and reported their progress.
  26.  
  27. International Concerns
  28.  
  29. Steve Carter, of Bellcore, presented the major international
  30. concerns.
  31.  
  32. Due to the concerns expressed at the November meeting about conversion
  33. to a Type I (international) X3 process, Steve came prepared with
  34. material explaining the implications of the change.  To all
  35. appearances, the change seems benign to the technical work of the
  36. committee.  The change would have the positive effect of getting
  37. international involvement.  It has the potential to delay the
  38. development of the standard, due to the need to synchronize U.S.  and
  39. ISO balloting.
  40.  
  41. The full X3J16 committee almost decided to vote to adopt the change,
  42. but ran out of the quorum necessary to pass the motion on Friday
  43. morning.
  44.  
  45. Editorial
  46.  
  47. Jonathan Shopiro, of AT&T, presented the Editorial group's
  48. work.
  49.  
  50. The most significant change from the November version was the
  51. incorporation of the exception handling proposal.  Jonathan also
  52. described an editorial change that simplified the treatment of names
  53. and name lookup, merging the concepts that had previously been treated
  54. under the topics of dominance and name hiding.  Martin O'Riordan, of
  55. Microsoft, questioned whether this was a purely editorial change, or a
  56. change to the language semantics.  Martin and others reqeusted time to
  57. look over the change before agreeing to it.
  58.  
  59. As I mentioned last time, the person who volunteered to edit the
  60. Rationale document has not been heard from since last summer.  Susan
  61. Waggoner, of USWest, has taken on that responsibility.
  62.  
  63. Formal Syntax
  64.  
  65. James Roskind, an independent consultant, presented the work
  66. of the Formal Syntax group.
  67.  
  68. The bulk of the discussion concerned a proposal by Reg Charney of
  69. Program Conversions, Inc. to rename the non- terminals in the
  70. grammar.  Although there was much discussion about the virtues of
  71. regularizing the naming versus the evils of gratuitous changes, the
  72. committee decided, in the end, to adopt the proposal.
  73.  
  74. Eric Krohn, of Bellcore, presented the syntactic ambiguities involving
  75. the newly-adopted throw-expression syntax for exceptions.  The
  76. discussion clarified the issues, and a final resolution is likely next
  77. meeting.
  78.  
  79. Tom Penello, of Metaware, gave an interesting presentation on the
  80. inherent problems with ambiguous grammars.  He established the fact
  81. that an ambigous grammar makes the question of a conforming
  82. implementation undecidable.  He also illustrated that arbitrary rules
  83. to resolve grammatical ambiguities has the side-effect of rejecting
  84. valid programs.
  85.  
  86. He then went on to explain the syntactic ambiguities of the template
  87. syntax, arising from the conflict over using the ``>'' symbol as both
  88. a relational operator and a template argument list delimiter.
  89. Although he proposed a grammar rewrite that solved the problem, he
  90. decided not to recommend it on aesthetic grounds.
  91.  
  92. There seems to be an appreciation within X3J16 as a whole for the
  93. technical issues involved in making the grammar correct.  There also
  94. seems to be a sentiment in favor of letting the semantic rules settle
  95. most of the complex issues.
  96.  
  97. Core Language
  98.  
  99. Andy Koenig, of AT&T, presented the Core Language group's
  100. work.
  101.  
  102. Document X3J16/91-0005 describes the group's discussion about the
  103. linkage of typedef names and anonymous classes.  The group decided it
  104. was an Environmental issue, and handed it off to the Environment group.
  105.  
  106. The group discussed objects created under a condition, and resolved to
  107. consider those objects governed by an implicit block scope, as if the
  108. programmer had explicitly supplied a compound statement.  Discussion
  109. is summarized in X3J16/91- 0021.
  110.  
  111. Document 91-0019 covers the discussion of lifetimes for temporary
  112. objects created by the compiler.  This issue has not reached closure,
  113. although the issues were clarified.
  114.  
  115. Environment
  116.  
  117. Peter Chapin, of Vermont Technical College, presented the
  118. work of the Environment group.
  119.  
  120. Document X3J16/91-0011 describes the group's discussion about C/C++
  121. compatibility issues.  This discussion is continuing.
  122.  
  123. The group discussed at length the one definition rule - enforcing the
  124. rule that a program must have exactly one definition for a given
  125. function, even in the presence of multiple inclusions of inline
  126. functions and the potential need for the compiler to generate such
  127. functions out of line.  Document X3J16/91-0024 summarizes the
  128. discussion.
  129.  
  130. There is a proposal to include a section in the standard on required
  131. warnings.  Laura Yaker, now at Mentor Graphics, presented some ideas
  132. of the sorts of things that might be considered as required warnings.
  133. The discussion indicated that this is a difficult issue to
  134. standardize, since there is so much variation in environments and
  135. implementations.  This ongoing discussion is summarized in
  136. X3J16/91-0014.
  137.  
  138. Another ongoing discussion concerns static initialization order for
  139. objects in different translation units.  Document X3J16/91-0012
  140. summarizes this discussion.
  141.  
  142. There was some discussion on specifying translation limits in the
  143. standard.  The discussion seemed to generate more heat than light, and
  144. nothing was decided.
  145.  
  146. Lastly, the linkage of types discussion continues, and is summarized
  147. in X3J16/91-0023.  Peter described several alternate rules to insure
  148. type-safe linkage of types.  A central issue is whether the linkage
  149. specification is part of the type.  There are interesting arguments
  150. for and against this.
  151.  
  152. Libraries
  153.  
  154. I presented the Library group's work.
  155.  
  156. There has been some progress on formulating proposals for submission
  157. to X3J16.  Aron Insinga of DEC presented his proposal to apply
  158. templates to the definition of the standard string class.  His
  159. progress has been slowed by the lack of an available implementation
  160. supporting templates.
  161.  
  162. Steve Clamage of TauMetric presented proposed resolutions for almost
  163. all of the compatibility issues regarding the C library.  Most of the
  164. small type insecurities can be handled in a reasonably straightforward
  165. manner.  There are more substantial issues regarding signals,
  166. exceptions and the facilities provided by longjmp().
  167.  
  168. The iostreams proposal continues to receive comment.  Many of the
  169. UNIX-specific issues have been removed.  Addressing these concerns
  170. raised an interesting point - should the C++ standard adopt the
  171. practice of the C standard, in describing only that certain 'types'
  172. exist, or should it describe them as classes and specify their
  173. required operations?  There was some concern that describing classes
  174. would be inefficient, but other concerns that the vague wording
  175. without a class description would introduce too much variability among
  176. implementations.
  177.  
  178. Language Extensions
  179.  
  180. Bjarne Stroustrup, of AT&T, presented the work of the
  181. Extensions group.
  182.  
  183. The group is working through a long list of proposals for changes to
  184. the language.  A significant number of them came from the Core
  185. language group, due to an evaluation of what Andy Koenig calls for
  186. changing the wording of the standard would have the effect of changing
  187. the meaning of the language.
  188.  
  189. The current list of language extension proposals includes overloading
  190. of the ``.'' operator, a proposal for handling national character set
  191. issues with digraphs and new keywords, and the adoption of the
  192. ``inherited'' keyword (as in Apple's implementation).
  193.  
  194. The largest issue lurking in the Extensions category is the addition
  195. of support for run-time type information.  There will be much
  196. discussion on this topic over the next months.
  197.  
  198. C Compatibility
  199.  
  200. Tom Plum, of Plum-Hall, presented the work of the C
  201. Compatibility group.
  202.  
  203. The group continued its investigation of the vocabulary differences
  204. between C and C++.  They decided to categorize their efforts into
  205. groups, covering the language, environment, and library.  One likely
  206. outcome of their work will be a proposal to adopt the same model of
  207. sequence points used by X3J11.
  208.  
  209. Next events
  210.  
  211. The next three X3J16 1991 meetings (and their hosts) will
  212. be:
  213.  
  214.    o June 17-21, Lund Sweden (Lund Institute of Technology)
  215.  
  216.    o November 11-15, Toronto Canada (IBM)
  217.  
  218.    o March 1992, Austin TX (TI)
  219.  
  220. Zortech announced plans to host one of the other two 1992 meetings in
  221. London.
  222.  
  223. Membership on an X3 committee is open to any individual or
  224. organization with expertise and material interest in the topic
  225. addressed by the committee.  The cost for membership is $250.  Contact
  226. the chair or vice chair for details.
  227.  
  228. Chair:
  229.    Dmitry Lenkov
  230.    HP California Language Lab
  231.    19447 Pruneridge Avenue MS 47 LE
  232.    Cupertino,
  233.    CA 95014
  234.    + 1 (408)447-5279
  235.    FAX: +1 (408)447-4924
  236.    email dmitryhpda@hplabs.hp.com
  237.  
  238. Vice Chair:
  239.    William M. Miller
  240.    Glockenspiel, Ltd
  241.    P.O.Box 366
  242.    Sudbury,
  243.    MA 01776-0003
  244.    +1 (508)443-5779
  245.    email wmmiller@cup.portal.com
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302. Volume-Number: Volume 24, Number 24
  303.  
  304.