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