This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.

383. Bidirectional iterator assertion typo

Section: 25.3.5.6 [bidirectional.iterators] Status: CD1 Submitter: ysapir (submitted via comp.std.c++) Opened: 2002-10-17 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [bidirectional.iterators].

View all issues with CD1 status.

Discussion:

Following a discussion on the boost list regarding end iterators and the possibility of performing operator--() on them, it seems to me that there is a typo in the standard. This typo has nothing to do with that discussion.

I have checked this newsgroup, as well as attempted a search of the Active/Defect/Closed Issues List on the site for the words "s is derefer" so I believe this has not been proposed before. Furthermore, the "Lists by Index" mentions only DR 299 on section 24.1.4, and DR 299 is not related to this issue.

The standard makes the following assertion on bidirectional iterators, in section 24.1.4 [lib.bidirectional.iterators], Table 75:

                         operational  assertion/note
expression  return type   semantics    pre/post-condition

--r          X&                        pre: there exists s such
                                       that r == ++s.
                                       post: s is dereferenceable.
                                       --(++r) == r.
                                       --r == --s implies r == s.
                                       &r == &--r.

(See http://lists.boost.org/Archives/boost/2002/10/37636.php.)

In particular, "s is dereferenceable" seems to be in error. It seems that the intention was to say "r is dereferenceable".

If it were to say "r is dereferenceable" it would make perfect sense. Since s must be dereferenceable prior to operator++, then the natural result of operator-- (to undo operator++) would be to make r dereferenceable. Furthermore, without other assertions, and basing only on precondition and postconditions, we could not otherwise know this. So it is also interesting information.

Proposed resolution:

Change the guarantee to "postcondition: r is dereferenceable."

Rationale:

Fixes an obvious typo