|
Boost : |
From: Raoul Gough (RaoulGough_at_[hidden])
Date: 2004-02-07 16:36:03
"Rani Sharoni" <rani_sharoni_at_[hidden]> writes:
> Raoul Gough wrote:
>> struct A { A &as_lvalue () { return *this; } };
>>
>> void foo (A const &);
>>
>> void bar () {
>> foo (A()); // #1 Can copy
>> foo (A().as_lvalue()); // #2 Can't copy
>> }
>
> Lately we discovered that there is difference between #1 and #2
> since #1 might produce a const object, since in case that additional
> temporary is introduced it is const, with all the following
> consequences (e.g. potential const optimizations that no compiler
> actually do).
The thing I've never understood about the copyable requirement is that
I don't see what it gains for me, the programmer. OK, maybe if the
compiler is allowed to introduce a temporary, it might be able to make
the code run faster in some cases. I'll believe that if and when I
ever see it myself. Surely a compiler that is smart enough to do that
could decide to do it anyway with an "as-if" justification. It could
also decide not to do it if the copy constructor isn't available (and
surely it would have to be trivial or at least inline if it supposed
to gain performance somehow).
Anyway, for many if not most UDTs, calling the copy constructor is
going to reduce performance significantly. I wonder if potential
optimizations were ever the real reason for including this
requirement? Maybe it just makes a compiler easier to implement, but
that would be a poor trade off, IMHO.
-- Raoul Gough. export LESS='-X'
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk