Boost logo

Boost :

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-10-14 01:49:42

>From: "David Abrahams" <dave_at_[hidden]>

>Terje Slettebø <tslettebo_at_[hidden]> writes:

>> I didn't mean to present it as an argument for const temporaries. I
>> pointed out that doing --c.end() is inherently unsafe, unless you know
>> the iterator is implemented, on all the platforms you use it.

>I see how it's non-portable, but unsafe? How so?

Hm, maybe not. I hadn't studied the sequence requirements, prior to this. I
realise now, as also Joe and Howard points out, that if a container has
bidirectional/random access iterators, then it's reversible, and it has to
be able to provide a reverse iterator with reverse_iterator(c.end()).

I was thinking of e.g. a double-linked list, where the begin() iterator is a
pointer to the first node, and the end() iterator is a null pointer. That
way, if you advance through the list, iterator=iterator->next, in the end,
iterator==NULL, and it will compare equal to the end() iterator, so such an
end() iterator would work. However, it would not satisfy the requirements of
bidirectional iterators, as you couldn't obtain a reverse iterator from

To satisfy that requirement, end() needs to have enough information to
construct a reverse iterator, using reverse_iterator(). That means providing
a valid operator--(), that reverse_iterator() may change to operator++().

Thus, I agree with you, and also as Howard said, --c.end() may fail to
compile (if it returns a const value), but if it compiles, it should be
safe. Also because begin()/end() are required to return an iterator by value
(not by reference), so that also means it can't mess up the container after



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