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

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-13 14:34:00

"Andrei Alexandrescu" <andrewalex_at_[hidden]> writes:

> "Mattias Flodin" <flodin_at_[hidden]> wrote in message
> news:20021012213714.GA4386_at_krona.cs.umu.se...
>
> > Why would I want to communicate information about what my
> > implementation does in the function interface? I don't see why
> > putting const there would be a lie; more like information hiding,
> > which is usually considered a good thing.<
> 
> The interface of the function doesn't change in the least whether you take a
> value or a reference to const. As far as your clients are concerned, the
> deal is the same.

The value parameter restricts arguments to those that are
copy-constructible. However, if you're going to copy-construct the
value internally, which I guess is your premise, then yes, the deal is
the same.

> Couldn't find a specific other post to stick this to, so here I'd like to
> thank all, especially Terje, who participated to the RVO and NRVO
> measurements and discussion.
> 
> I need to mollify my arguments against the lying const. But only a bit! The
> operator+ example shows that many compilers prefer const T& as the first
> argument in certain cases. However, in the case of assignment:
> 
> T& operator=(const T& src)
> {
>     T copy(src);
>     copy.swap(*this);
>     return *this;
> }
> 
> versus:
> 
> T& operator=(T src)
> {
>     src.swap(*this);
>     return *this;
> }
> 
> I'd be quite surprised of the compiler could go past the const in the
> argument.

Even if it's all available to the compiler in the form of
inline/template function implementations? If the compiler can prove
the forms are equivalent, the optimization is surely allowed. Is it
possible that the 2nd form turns out to be better because the compiler
is not allowed to elide the explicit copy in the first line of the
first form's function body, even if the forms are not equivalent?

> Also, if a temporary is passed as the first argument to operator+, that also
> might engender an unnecessary temporary. So "lying const" is too strong,
> maybe I should go for evidentiating the opposite case, "The Friendly
> Pass-By-Value" :o).
> 
> Anway, with ZUTO, the implementation of operator+ that is guaranteed to not
> copy temporaries unnecessarily is the one that takes lhs by value. (Same
> about operator=.) 

Uh, it takes the lhs of the *assignment* by value? I guess that's
where a generic version of auto_ptr_ref can help out... but, wait, the
assignment operator has to be a member; you don't get to choose the
type of the lhs...

...you know, this discussion would be a lot easier if you'd just raise
a corner of the black velvet cloth. You don't have to show us the
whole girl, but it'd be nice to see her toes wiggling before you go
ahead and saw her in half. 

> P.S. The interest in ZUTO is staggering. The number of volunteering
> reviewers has hit 70. If I made any mistake, I'm toast!!! :o)

It's not too surprising to me. I think anyone who advertised in all
the major forums claiming a "revolution" in efficiency, and showing no
details, would be likely to receive as many offers from people wanting
to know what all the hoopla was about.

Still-wondering-ly y'rs,
Dave

-- 
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com