This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 23.2.4[sequence.reqmts]Status:CD1Submitter: Yaroslav MironovOpened: 2002-01-23Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [sequence.reqmts].
View all otherissues in [sequence.reqmts].
View all issues withCD1 status.
Discussion:
Table 68 "Optional Sequence Operations" in 23.1.1/12specifies operational semantics for "a.back()" as"*--a.end()", which may be ill-formed[because callingoperator-- on a temporary (the return) of a built-in type isill-formed], provided a.end() returns a simple pointer rvalue(this is almost always the case for std::vector::end(), forexample). Thus, the specification is not only incorrect, itdemonstrates a dangerous construct: "--a.end()" maysuccessfully compile and run as intended, but after changing the typeof the container or the mode of compilation it may producecompile-time error.
Proposed resolution:
Change the specification in table 68 "Optional SequenceOperations" in 23.1.1/12 for "a.back()" from
*--a.end()
to
{ iterator tmp = a.end(); --tmp; return *tmp; }and the specification for "a.pop_back()" from
a.erase(--a.end())
to
{ iterator tmp = a.end(); --tmp; a.erase(tmp); }[Curaçao: LWG changed PR from "{ X::iterator tmp =a.end(); return *--tmp; }" to "*a.rbegin()", and from"{ X::iterator tmp = a.end(); a.erase(--tmp); }" to"a.erase(rbegin())".]
[There is a second possible defect; table 68 "OptionalSequence Operations" in the "Operational Semantics"column uses operations present only in the "ReversibleContainer" requirements, yet there is no stated dependencybetween these separate requirements tables. Ask in Santa Cruz if theLWG would like a new issue opened.]
[Santa Cruz: the proposed resolution is even worse than what's in the current standard: erase is undefined for reverse iterator. If we're going to make the change, we need to define a temporary and use operator--. Additionally, we don't know how prevalent this is: do we need to make this change in more than one place? Martin has volunteered to review the standard and see if this problem occurs elsewhere.]
[Oxford: Matt provided new wording to address the concerns raised in Santa Cruz. It does not appear that this problem appears anywhere else in clauses 23 or 24.]
[Kona: In definition of operational semantics of back(), change"*tmp" to "return *tmp;"]