Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-03-18 11:09:38

At 05:22 PM 3/17/2001, Jeremy Siek wrote:

>On Sat, 17 Mar 2001, John E. Potter wrote:
>jpotte> Sorry for being out of contact, but I only have time to
>jpotte> delete without reading most of the boost stuff for now.
>jpotte> The action of iter[n] is the same as *(iter + n) and in
>jpotte> both cases should be a reference or reference to const.
>jpotte> I know that the standard says convertable to T, but
>jpotte> forward iterator has it right and there is an issue.
>There is a subtle problem with using reference return for
>iterator_adaptor::operator[]. The problem shows up for iterators like
>counting_iterator that return a reference to a value object that is part
>of the iterator object itself, and has the same lifetime as the iterator.
>The expressions (iter + n) creates a temporary iterator object, then
>*(iter + n) returns a reference to part of this temporary iterator
>Upon return from operator[], the temporary iterator goes away and we are
>left with a dangling reference.
>One option is to say iterator_adaptor can't be used with this kind of
>iterator. However, if a user were to go ahead and use such an iterator,
>they would not find out about the problem until run time! Even so I'm
>slighly in favor of this option, but Dave is strongly against it.

Note that the C++ committee's Library Working Group has an open issue:

198. Validity of pointers and references unspecified after iterator

Matt Austern has been working on a new proposed resolution which includes
my original general fix plus Andy Koenig's very perceptive fix to
reverse_iterator. Matt is very concerned about operator[]; you might want
to take this up with him privately.


Boost list run by bdawes at, gregod at, cpdaniel at, john at