On Wed, Apr 24, 2013 at 10:24 PM, Andrew Ho
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():
Rvalues, not rvalue references :) The above obviously would (likely) have dangling reference issues. [...]
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.
Maybe we're talking past each other. I have 3 overload set variants in mind: (A) T operator?(T, T); (B) T operator?(T const &, T const &); ... T operator?(T&&, T&&); (C) T operator?(T const &, T const &); ... T&& operator?(T&&, T&&); AFAICT, neither (A) nor (B) have any safety issues. Oh, but now I see the problem with (C): T&&'s are implicitly convertible to T&'s...that's what I was missing before. Sorry for being dense. So if you do T& a = b + c; you'll get a compiler error with (A) or (B) and a runtime error with (C). Well, maybe you can return a wrapped T&& with an implicit conversion operator to T&&: wrapped_rref<T> operator?(T&&, T&&); where template< class T > struct wrapped_rref { operator T&&() const; operator T const &() const; }; Not sure offhand if that would even prevent the T& a = b + c; usage, nor if it would handicap many other common use cases.
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?
The former, for sure. I assume you mean (C) above for the latter. - Jeff