Re: [boost] [xint] Third release is ready, requesting preliminary review

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-05-03 13:45:03

On 5/3/2010 9:57 AM, Chad Nelson wrote:
> On 05/03/2010 12:35 PM, Juergen Hunold wrote:
>> And I wonder about "return BOOST_XINT_MOVE(p);" instead of "return
>> p;" and let the compiler optimise the return via NRVO...
>
> Does NRVO work with emulated move semantics? I was under the impression
> that it couldn't, but I could well be wrong, Boost.Move is new to me.

RVO works independently of (emulated) move semantics.  If you have the 
following code (similar example as before):

T f() { return T(...); }
void g(T) { ... }

then in the expression "g(f())", the compiler is allowed to elide the 
copy from the return statement in f() all the way to the T parameter in 
g (and most compilers will perform this copy elision).  In practice, the 
copy constructor of T is never called (except, of course, where it is 
used explicitly in the body of f and g)!  Similarly, the statement "T x 
= f();" ostensibly requires 1 or more calls to T's copy constructor, 
but, again, in practice, most modern compilers elide these away.

Actually, if f is defined as

T f() { return move(T(...)); }

then this could actually be *less* efficiently, since it will invoke an 
additional move construction over using the original definition of f!

One of the main things (emulated) move semantics gives you is the 
ability to overload functions on lvalue or (emulated) rvalue reference, 
giving you the opportunity to capture temporaries and pilfer/reuse their 
resources.

- Jeff