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

Subject: Re: [boost] [operators] The future of Boost.Operators
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-04-25 13:50:30

On Thu, Apr 25, 2013 at 10:03 AM, Marc Glisse <marc.glisse_at_[hidden]> wrote:

> 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'
>

Are you sure we're talking about the same thing? This looks like the kind
of error that (A) or (B) would produce; would not (C) say something like

invalid initialization of non-const reference of type 'T&' from type 'T&&'

???

I swear I just tried a T& y = static_cast<T&&>(x) on gcc and finding it
compiled fine.

> Now you can ask the same question with T const& instead...

Sure.