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

Subject: Re: [boost] [operators] The future of Boost.Operators
From: Andrew Ho (helloworld922_at_[hidden])
Date: 2013-04-24 16:36:38

> Remind me how the 4-overload-version is unsafe, again?

There's the potential for a user to assign a reference variable to an
invalid temporary:

T &var = a + b + c;

I am of the opinion this is a usage error (as is Daniel), but
none-the-less, was previously valid because the operators returned by
value. Just as large a problem is that if this error does occur in real
code (old or new), it can be difficult to identify.

> A macro which globally switches the effect of all uses of Boost.Operators?
> Let's avoid that.

We will need at least the compiler feature check switch since rvalue
references will cause compilers which don't support the feature fail. After
a little digging, the commutative operators will always need special
handling since they directly use rvalue refs.

On Wed, Apr 24, 2013 at 11:04 AM, Jeffrey Lee Hellrung, Jr. <
jeffrey.hellrung_at_[hidden]> wrote:

> On Tue, Apr 23, 2013 at 11:06 PM, Andrew Ho <helloworld922_at_[hidden]>
> wrote:
>
> > Here's a thought about the direct use of r-value references vs. pass by
> > value
> > argument:
> >
> > We are planning on providing a version which is supposed to support
> > compilers
> > without move semantics. However, these implementations are close to,
> > perhaps
> > even exactly identical to the code that would take advantage of move
> > semantics
> > via pass by value.
> >
> > Say we allowed a user-accessible define which would allow the programmer
> to
> > decide?
> >
>
> A macro which globally switches the effect of all uses of Boost.Operators?
> Let's avoid that.
>
> something like:
> >
> > // BOOST_HAS_RVALUE_REFS is a feature availability check
> > // BOOST_UNSAFE_MOVE is user-definable override to use faster, unsafe
> > version
> > #if defined(BOOST_HAS_RVALUE_REFS) && defined(BOOST_UNSAFE_MOVE)
> > // use 4 overload version
> > #else
> > // use pass-by-value version
> > #endif
> >
> > If the user is more concerned with safety over micro-optimizations, the
> > default behavior would resort to pass by value (good for backwards
> > compatibility).
> >
>
> Remind me how the 4-overload-version is unsafe, again?
>
> However, the user would have the option available to easily use the faster
> > version if they deem it necessary.
> >
>
> - Jeff
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Andrew Ho