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

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