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-24 17:41:34

On Wed, Apr 24, 2013 at 1:36 PM, Andrew Ho <helloworld922_at_[hidden]> wrote:

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

Does operator+ return by value or by reference? If it returns by value, how
is the above possible? Is T a typedef or template parameter for a
const-qualified type in your example above?

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.

Okay, now I'm really confused. I would think return-by-reference would
allow the above, but return-by-value would not.

And how is this related to whether operator+'s parameters are by-value (1
overload) or by-reference (4 overloads)? I mean, other than the former
precluding return-by-reference, of course.

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.

Yeah, that's fine; you're switching on compiler features, and you're
switching to an objectively better implementation.

Having a macro that switches *all* uses of Boost.Operators to either "safe"
or "fast" (whatever those mean) implies that you can't mix safe uses with
fast uses.

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
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>