Re: [boost] Re: Re: Re: Zero Unnecessary Temporary Objects: ARevolution

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

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

>"Victor A. Wagner, Jr." <vawjr_at_[hidden]> writes:

>> At Sunday 2002/10/13 16:39, you wrote:
>>
>> >"Terje Slettebø" <tslettebo_at_[hidden]> wrote in message
>> >news:058901c272c8$a261f6b0$60fb5dd5_at_pc...
>> > >From: "Yitzhak Sapir" <yitzhaks_at_[hidden]>
> >
> > >As I understand, the only thing you can safely do with an end()
iterator is
> > >to compare it with other iterators.
> >
> >    If operator-- is defined on an iterator, and begin() != end(), then
it is
> >also safe to decrement an iterator that is equal to end().
> >reverse_iterators depend on this fact.  This is why rbegin().base() ==
> >end().
>
> I don't see how that follows.  I agree that rbegin().base() == end(),
> but don't see how that implies that ANY operations on end() are legal.

>Well, nothing needs to allow operations on end(), because nothing
>forbids it. In general, the rule is: if the standard doesn't forbid
>it, it is allowed.

>That aside, the implementation of reverse_iterator is clearly spelled
>out in the standard:

>    [lib.reverse.iter.op++]
>    24.4.1.3.5 operator++
>    reverse_iterator& operator++();
>    1 Effects: --current;

>So, Terje's argument holds water.

I think there might have been a mixup in the quoting here, as the argument
that operator--() is safe, because of the requirement that you can do
reverse_iterator(c.end()), was by Yitzhak, not me. Although I've come to
that I agree. :)

Regards,

Terje