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

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-10-12 12:11:10

"Howard Hinnant" <hinnant_at_[hidden]> wrote in message
news:429A3202-DDEF-11D6-99E6->
>I think there are some existing valuable programming patterns for
performing non-const operations on temporaries.<

I agree with Howard wholeheartedly.

>The misuses that arise from returning a non-const T don't really seem
to occur in practice.  How many times have you seen this outside of
contrived example code?

(s1 + s2) = s3;

It sticks out like a sore thumb.  It just doesn't happen by accident.<

Very nice, levelheaded considerations. Cool, Howard!

>Looking to the future, it is possible that non-const temporaries will
become vastly more useful than const temporaries (much more so than
demonstrated in my string example).  I am specifically talking about
the move proposal:

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm

In this system, one can move from non-const temporaries, with no
additional syntax required over today's copy syntax:

s3 = s1 + s2;  // temporary implicitly move assigned into s3<

BTW, that's exactly what ZUTO does without changes in the language :o). Not
to say that the language change wouldn't render programs clearer. And just
like in the proposal, const temporaries choke Zuto's ability to exploit move
construction.

Again (see my previous post here), a const temporary is a contradiction in
terms, a "lie". Temporary means: "I'm transient, I could change because all
I'm going to do soon is to die anyway!"

>Now it is definitely premature to start designing around this proposal.
  It has not yet even been discussed in committee, and the final result
(if there is a result) will likely look very different.  But there is
great interest in some kind of move facility throughout the C++
community.  And the only proposed solution to date suggests there might
be an important use for non-const temporaries.  So it just seems to me
that now is not the time to go sticking const on a lot of
return-by-value functions just to make sure clients don't write
insanely stupid code:

(s1 + s2) = s3;

And this is doubly true when there exists today viable, valid code that
may need non-const temporaries to work.

s3 = (s1 + s2).replace(s1.size()-1, 2, "C4");<

Indeed. Great post, Howard!

>Assuming T::operator+= looks like:

T& T::operator+=(const T& rhs) { ... return this;}

The above approach is generally not optimizable via RVO.  The return
statement sees a T&.  Unless the compiler digs into op+=, it has no
reason to believe that the T& refers to the temporary.  Thus a copy of
the object referred to by the T& must be made.  If op+= returns by
value, then that is another story of course (and that is the case that
MEC++ #20 refers to).<

This summarizes exactly the same conclusions I recently came to. Passing by
const reference when you actually plan on making a copy is like not saying
what you're doing. Instead of letting the compiler deal with creating copies
and dealing with them, you prefer to lie to it and create your copies by
hand.

Zuto prescribes a three-fanged convention for passing parameters to
functions:

* If you /always/ need to create a copy, take the parameter by value so you
own the copy.

* If you /never/ need to create a copy, take the parameter by const
reference.

* If you /sometimes/ need to create a copy /and/ you care about efficiency,
follow the Zuto protocol.

Andrei

--
All new!  THE C++ Seminar: Oct. 28-30 in Vancouver, WA.
http://www.thecppseminar.com/