Boost logo

Boost :

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


>From: "Howard Hinnant" <hinnant_at_[hidden]>

>On Sunday, October 13, 2002, at 12:59 PM, Terje Slettebø wrote:

>> I'd like to get your comment on --c.end(), after reading the above, if
>> you
>> still think it's safe in the general case. Especially regarding the
>> guarantees given in the standard.

>I believe that --c.end() is safe and portable for those iterators that
>are both bidirectional and known to have non-pointer implementations.
>In the standard this includes list, deque, map, multimap, set and
>multiset. For string and vector, --c.end() is not portable. It is
>safe in the sense that it won't silently do the wrong thing. But it
>may fail to compile due to implementation details. You may call that
>unsafe. I may label it irritating. <shrug>

No, I agree with you. See my recent reply to Dave. I was thinking of if e.g.
end() returned NULL, so that operator--() would decrement NULL, and that one
might possibly apply operator*() on that. That's what I meant was unsafe.
However, as mentioned in the other posting, I realise that such a sequence
would not satisfy the bidirectional/random access sequence requirements.

Thus I agree that it may fail to compile, but if it does, it should be safe.
Provided the container follows the requirements in the standard, of course.

>> Why not instead use begin()+c.size()-1? It's safe and portable.

>It is safe and portable provided c supplies random access iterators.
>Another way to write it is:

>c.end() - 1

Yes, apparently it is. :)

You're right that this requires random access iterators, not just
bidirectional iterators. I didn't think of that.

>> Why take such unnecessary risks, when there are safe alternatives?

Never mind that. :) I realise it's safe after all, for conforming sequences.

Thanks for the replies, all.

Regards,

Terje


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