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@gmail.com> wrote:
On Tue, Apr 23, 2013 at 11:06 PM, Andrew Ho
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