This is a plain wording fixing proposal for the table-based requirement set of class template fpos. A paper is provided instead of drafting wording in the referenced issues, to have more room available for presentation and explanation.The wording changes suggested by this paper should not have effects on any existing implementations, because it mainly intended to clearify several underspecified parts of the current specification. Nonetheless during the analysis of the paper there occurred some curiosities in the specification that caused to ask some questions to the committee which might lead to decisions to change existing implementations, but the author has tried to be as conservative as possible in regard to such suggestions.
Changes since P0759R0:
Rebases to the reference working draft N4750
Get rid of the expression q + ol == p in Table 106 — "Position type requirements" including the additionally needed expression symbol ol that was needed only to specify the expression p - q. The author believes that the newly added assertion expression p == q + (p - q) is sufficient.
Add an operational semantics entry p + o to the expression row o + p in Table 106.
This paper revision does not repeat the sections Discussion, 1. Specification Facts, and 2. Specification Problems of its predecessor P0759R0.Please refer to the previous paper regarding general background and (extended) rationale.
If the proposed resolution will be accepted, the following library issues will be resolved:
|Number||Description||C++17 NB comment|
|2808||Requirements for fpos and stateT||GB 60|
|2832||§[fpos.operations] strange requirement for P(i)||—|
At some places below, additional markup of the form
[Drafting notes: whatever — end drafting notes]
is provided, which is not part of the normative wording, but is solely shown to provide additional information to the reader about the rationale of the concrete wording.
The proposed wording changes refer in all cases to N4750.
Change 22.214.171.124 [fpos.operations] as indicated:
Operations specified in Table 112 are permitted.In that table,
(1.1) — P refers to an instance of fpos,
(1.2) — p and q refer to values of type P ,
(1.3) — O refers to type streamoff,
(1.4) — o refers to a value of type streamoff
(1.5) — sz refers to a value of type streamsize and
(1.6) — i refers to a value of type int.
[Drafting notes: It is recommend to strike the non-normative note in p2 completely. This seems to be very out-dated wording and what is says is already said in 126.96.36.199 [structure.requirements], in particular in p3+p4 — end drafting notes]
-3- Stream operations that return a value of type traits::pos_type return P(O(-1)) as an invalid value to signal an error. If this value is used as an argument to any istream, ostream, or streambuf member that accepts a value of type traits::pos_type then the behavior of that function is undefined.
-2- [Note: Every implementation is required to supply overloaded operators on fpos objects to satisfy the requirements of 188.8.131.52 [fpos.operations]. It is unspecified whether these operators are members of fpos, global operators, or provided in some other way. — end note]
Change Table 106 — "Position type requirements", as indicated:
[Drafting notes: We can strike the wording about the destructor and ==, because we have now the EqualityComparable and Destructible requirements specified in 184.108.40.206 [fpos.operations] — end drafting notes]
Table 106 — Position type requirements Expression Return type Operational semantics Assertion/note
P(i) p == P(i)
note: a destructor is assumed.
P p = i;
Postconditions: p == P(i). P(o) fpos converts from offset
O(p) streamoff converts to offset P(O(p)) == p p == q convertible to bool == is an equivalence relation p != q convertible to bool !(p == q) q =p + o
p += o fpos + offset q - o == p q =p - o
p -= o fpos - offset q + o == p o =p - q streamoff distance
q + o == p streamsize(o)
streamsize(O(sz)) == sz
streamsize(O(sz)) == sz
N4750 Richard Smith: "Working Draft, Standard for Programming Language C++"
Thanks to Jonathan Wakely, Billy Robert O'Neal III, and Axel Naumann for a review of this proposal and for encouragement to make a little more changes as I originally believed I should make.