"Rani Sharoni" <rani_sharoni@hotmail.com> 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'