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

Subject: Re: [boost] [operators] The future of Boost.Operators
From: Marc Glisse (marc.glisse_at_[hidden])
Date: 2013-04-25 13:03:44

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

> On Wed, Apr 24, 2013 at 10:24 PM, Andrew Ho <helloworld922_at_[hidden]> 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