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

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-10-13 11:59:45

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

>On Saturday, October 12, 2002, at 11:19  PM, Terje Slettebø wrote:

>> From: "Howard Hinnant" <hinnant_at_[hidden]>
>
>> </philosophical on/>
>>
>> And hopefully not going to far off track here:  The automatic shoulder
>> strap belts that try to help by automatically placing the shoulder
>> strap around you, while leaving you with the job of attaching the lap
>> belt, are a menace to safety and I can't believe that they ever made
>> it
>> into public use.
>
> Do you here refer to the ordinary three-point seatbelts, with a fixed
> lower
> point, a rolling upper point, and the third other side lower point for
> attaching? If that's what you mean, I think that works very well, as
> you
> with one point attachment gives a three-point belt, so the attachment
> attaches both the diagonal and horizontal belt. Why would that be a
> menace
> to safety, and what would you recommend instead?

>I /knew/ I was getting too philosophical! :-)

:))

>I'm referring to the motorized rolling upper point.  The motorized
>action has led more than one inattentive person to believe that the car
>had fastened their safety belt for them.  So they did not even notice
>that their lap belt was left unfastened.

Aha.

>>> Fwiw, I've used --c.end() and am  not sorry for it! :-)
>>
>> If you do that on Intel C++ and STLPort for e.g. c=std::string, you
>> get a
>> compile-time error, as c.end() is not a modifiable lvalue. :) In other
>> words, whether or not that work depends on the platform, and is
>> therefore
>> not portable.

>I believe that this is a good argument for wrapping pointers up in an
>iterator adaptor.  I do not believe it is a good argument for making
>temporaries const.  --c.end() is not inherently unsafe.  It simply does
>not work if the iterator turns out to be a pointer.  This is a quirk of
>the language and nothing more.

I didn't mean to present it as an argument for const temporaries. I merely
pointed out that doing --c.end() is inherently unsafe, unless you know how
the iterator is implemented, on all the platforms you use it. Why not
instead use begin()+c.size()-1? It's safe and portable.

As pointed out in another posting, as I understand, the only thing you can
safely do with an end() iterator is to compare it with other iterators.
Without this guarantee, it would limit how you could implement the end()
iterator. See my other posting with the tree-iterators for an example. How
would you implement operator--() on that end() iterator?

Thus, it's not just for pointers that this may be a problem, but it could be
a larger problem for iterators that are UDTs, and which relies on only
comparision being performed for the end() iterator.

>So just because --c.end() compile-times if the iterator turns out to be
>a pointer, does not mean one should try to emulate this detail of
>pointer-iterators.

No. But the point is that requiring operator--() to work for end() may
prevent useful iterator implementations, as mentioned.

>If a class becomes too inconvenient to use, I'm
>either going to not use it, or subvert it.  Personally I find --c.end()
>(and potentially ++c.begin()) both safe and convenient.

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.

++c.begin() might be ok, unless it returns a reference, in which case you
risk screwing up the internals of the container.

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

>There is only one case I can think of where pointer-iterators are
>superior to (typical) class iterators:

>const_iterator ci = ...;
>iterator i = const_cast<iterator>(ci);

>I think this functionality (if not the precise syntax) would be a good
>thing to emulate.

It should be possible to get the same effect with an UDT, yes.

Regards,

Terje