Re: [boost] [operators] The future of Boost.Operators

On Thu, 25 Apr 2013, Jeffrey Lee Hellrung, Jr. wrote:

On Wed, Apr 24, 2013 at 10:24 PM, Andrew Ho wrote: [...]

...

...

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).

Er, no. That might be true with Microsoft's compiler and its extra "features", but regular compilers will complain: error: invalid initialization of non-const reference of type 'T&' from an rvalue of type 'T' Now you can ask the same question with T const& instead... -- Marc Glisse