Rationale:

This issue has been discussed extensively. Note that it is not an issue about the behavior of predefined iterators. It is asking whether or not user-defined iterators are permitted to have transient pointers and references. Several people presented examples of useful user-defined iterators that have such a property; examples include a B-tree iterator, and an "iota iterator" that doesn't point to memory. Library implementors already seem to be able to cope with such iterators: they take pains to avoid forming references to memory that gets iterated past. The only place where this is a problem is reverse_iterator, so this issue changes reverse_iterator to make it work.

This resolution does not weaken any guarantees provided by predefined iterators like list<int>::iterator. Clause 23 should be reviewed to make sure that guarantees for predefined iterators are as strong as users expect.

[ Copenhagen: Steve Cleary pointed out that reverse_iterator assumes its underlying iterator has persistent pointers and references. Andy Koenig pointed out that it is possible to rewrite reverse_iterator so that it no longer makes such an assupmption. However, this issue is related to issue 299. If we decide it is intentional that p[n] may return by value instead of reference when p is a Random Access Iterator, other changes in reverse_iterator will be necessary. ]

[ Pre-Toronto: Steve Cleary pointed out the no-invalidation assumption by reverse_iterator. The issue and proposed resolution was reformulated yet again to reflect this reality. ]

[ Post-Tokyo: The issue has been reformulated purely in terms of iterators. ]

Proposed resolution:

Add a new paragraph to [iterator.concepts]:

Destruction of an iterator may invalidate pointers and references previously obtained from that iterator.

Replace paragraph 1 of [reverse.iter.conv] with:

Effects:

  this->tmp = current;
  --this->tmp;
  return *this->tmp;

[Note: This operation must use an auxiliary member variable, rather than a temporary variable, to avoid returning a reference that persists beyond the lifetime of its associated iterator. (See [iterator.concepts].) The name of this member variable is shown for exposition only. --end note]

Is a pointer or reference obtained from an iterator still valid after destruction of the iterator?

Is a pointer or reference obtained from an iterator still valid after the value of the iterator changes?

#include <iostream>
#include <vector>
#include <iterator>

int main()
{
    typedef std::vector<int> vec_t;
    vec_t v;
    v.push_back( 1 );

    // Is a pointer or reference obtained from an iterator still
    // valid after destruction of the iterator?
    int * p = &*v.begin();
    std::cout << *p << '\n';  // OK?

    // Is a pointer or reference obtained from an iterator still
    // valid after the value of the iterator changes?
    vec_t::iterator iter( v.begin() );
    p = &*iter++;
    std::cout << *p << '\n';  // OK?

    return 0;
}

The standard doesn't appear to directly address these questions. The standard needs to be clarified. At least two real-world cases have been reported where library implementors wasted considerable effort because of the lack of clarity in the standard. The question is important because requiring pointers and references to remain valid has the effect for practical purposes of prohibiting iterators from pointing to cached rather than actual elements of containers.

The standard itself assumes that pointers and references obtained from an iterator are still valid after iterator destruction or change. The definition of reverse_iterator::operator*(), [reverse.iter.conv], which returns a reference, defines effects:

Iterator tmp = current;
return *--tmp;

The definition of reverse_iterator::operator->(), [reverse.iter.op.star], which returns a pointer, defines effects:

return &(operator*());

Because the standard itself assumes pointers and references remain valid after iterator destruction or change, the standard should say so explicitly. This will also reduce the chance of user code breaking unexpectedly when porting to a different standard library implementation.