Document No.: X3J16/94-0043 WG21/N0430 Date: March 4, 1994 Project: Programming Language C++ Reply to: Steve Rumsby steve@maths.warwick.ac.uk UK Position on C++ Working Paper Steve Rumsby Sean Corfield 1. Introduction Our current schedule lists the July 1994 meeting as the point at which we will vote on submission of the working paper as it exists then for CD registration. In preparation for this vote, the British Standards Institute C++ panel, IST/5/-/21, has been carrying out a detailed review of the working paper in its current form, in order to identify areas needing attention to ensure that it will be acceptable to the ISO national bodies during that ballot. This paper details our current areas of concern. The issues are split into two lists. The ``major issues'' are those that would cause the UK delegation at the July meeting to vote against submission. If the working paper were to be submitted anyway (i.e. the majority of ISO dele- gations were in favour of submission), these issues would probably cause our parent committee, IST/5, to vote against CD registration in the ballot. The ``minor issues'' are issues that we feel must be resolved eventually, but are not important enough of themselves to prevent CD registration. They may, however, become more important as time progresses (i.e. if not resolved they may cause the UK to vote against progression of the document in future ballots). 2. Major issues 2.1. Issues currently in boxes in the working paper The majority of these issues shall have working resolutions in the working paper. We feel that a committee draft should not be so visibly incomplete. 2.2. Terminology issues There are many inconsistencies in terminology in the current working paper, and many uses of language that would be hard to understand for a non-native English speaker. In particu- lar, we feel that the following must be fixed: . ``correct'', ``erroneous'', and similar words shall be replaced by ``ill-formed'' or ``well-formed'' as appro- priate. . in some places the phrase ``implementation dependent'' is used, but this is not defined by the working paper. This phrase shall have a definition, or shall not be used. . the definition of ``implementation defined'' states that the standard will delineate the range of allowable behaviours. In fact, there are cases where it cannot - this delineation should be optional. . the definition of ``unspecified'' states that the stan- dard will delineate the range of allowable behaviours. This is not done consistently. All uses of ``unspeci- fied'' shall specify the range of allowable behaviours. . all uses of ``may not'' shall be removed. Most uses seem to require ``shall not'', but some are ambiguous. . all other uses of ``may'' shall be reviewed. These are likely to be particularly confusing to non-native English speakers. . We would like to see all uses of the word ``pointer'' qualified with ``to object'', ``to function'', or ``to member'' as appropriate. Since these are distinct types, and generally have different representations, we feel this is an important and necessary qualification. 2.3. Lvalues and rvalues We feel that the meanings given to the terms ``lvalue'' and ``rvalue'' by the working paper are not the commonly accepted meanings, and are not particularly intuitive mean- ings. In particular, if use of this terminology persists, we require that the term ``rvalue'' shall not describe a value that refers to an object. More generally, we feel that the lvalue/rvalue model itself is flawed in the context of C++. 2.4. Memory model We feel that the current memory model does not adequately describe the conceptual lifetimes of memory and objects in C++. In particular, the lifetimes of an object and its underlying memory are not always coincident. The memory model shall be revised to take account of this, and we sup- port, in general principles, the memory model and object model put forward by John Skaller. 2.5. Miscellaneous issues The truncation of floating point values when converted to integer values, shall be more precisely specified. For exam- ple: For a floating point number F and a positive inte- ger N, with N<=F