Re: [boost] Re: Re: Zero Unnecessary Temporary Objects: A Revolution

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
merely
>> pointed out that doing --c.end() is inherently unsafe, unless you know
how
>> 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
NULL.

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
all.

Regards,

Terje