Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk