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 12:47:31

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

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