This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
Section: 188.8.131.52 [fpos.operations] Status: New Submitter: Jonathan Wakely Opened: 2018-06-04 Last modified: 2022-05-01
View all other issues in [fpos.operations].
View all issues with New status.
The fpos requirements do not give any idea what is compared by operator== (even after Daniel's P0759R1 paper). I'd like something to make it clear that return true; is not a valid implementation of operator==(const fpos<T>&, const fpos<T>&). Maybe in the P(o) row state that "p == P(o)" and "p != P(o + 1)", i.e. two fpos objects constructed from the same streamoff values are equal, and two fpos objects constructed from two different streamoff values are not equal.
[2018-06-23 after reflector discussion]
Priority set to 4
[2022-05-01; Daniel comments and provides wording]
The proposed wording does intentionally not use a form involving addition or subtraction to prevent the need for extra wording that ensures that this computed value is well-defined. According to 31.2.2 [stream.types], streamoff is a signed basic integral type, so we know what equality means for such values.
This wording is relative to N4910.
Modify in 184.108.40.206 [fpos.operations] as indicated:
[Drafting note: The return type specification of operator== should be resolved in sync with D2167R2; see also LWG 2114.]
(1.1) — […]
(1.5) — o refer
sto avalue of type streamoff or const streamoff.
Table 119: Position type requirements [tab:fpos.operations] Expression Return type Operational
… P p(o);
P p = o;
Effects: Value-initializes the
Postconditions: p == P(o)
… O(p) streamoff converts to offset P(O(p)) == p p != q convertible to bool !(p == q) …