[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [operators] The future of Boost.Operators
From:       Andrew Ho <helloworld922 () gmail ! com>
Date:       2013-04-25 5:24:43
Message-ID: loom.20130425T064402-63 () post ! gmane ! org
[Download RAW message or body]

> 1) Please don't top-post.

Oops, my bad. Mail client/user fail.

> 3) I suspect if you did T& x = f() + g(), where f() and g() are rvalues,
> you'd be in trouble.

I take it you have:

T&& f();
T&& g():

correct? This does indeed fail, but this will fail using either r-value refs 
or just return by value operator overloading. In fact, this fails for me 
even if I tried:

T x = f() + g();

In all cases, the temporary destructor was being called as a result of f() 
or g() returning, not a result of operator overloading definition or type of 
x.

Changing the definitions to:

T f();
T g();

and both operator overloading implementations (r-value refs or return by 
value) succeeds. I don't quite understand why the r-value refs operator 
overloads are able to extend the lifetime of the rvalues even though the 
function return rvalues don't have their lifetimes extended.

Again, I'm not sure if there is some VS2012 specific behavior going on.

> 2) I think my responses below still apply.

Are you referring to using a user-accessible macro switch, or the problems 
associated with using the 4-overloads? 


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]