Re: [boost] [proposal] raw move

Subject: Re: [boost] [proposal] raw move
From: Eric Niebler (eric_at_[hidden])
Date: 2011-08-23 12:06:46

On 8/23/2011 11:35 AM, Julian Gonggrijp wrote:
> Eric Niebler wrote:
> 
>> On 8/23/2011 8:06 AM, Julian Gonggrijp wrote:
>> <snip>
>>> [...]
>>> template <class T>
>>> void move_raw (typename UNDERLYING_TYPE(T)& source, T& target) {
>>>    target = source;
>>> }
>>
>> Yikes, no. T's copy constructor can throw. This should be a move, and
>> then only if T's move assign cannot throw. Otherwise, move_raw should
>> probably be undefined.
> 
> If move_raw is implemented as a copy, it doesn't really matter if the 
> copy throws because the source object is left in a valid state, right? 

No. Imagine:

  UNDERLYING_TYPE(X) tmp1;
  UNDERLYING_TYPE(Y) tmp2;
  move_raw(x, tmp1); // 1
  move_raw(y, tmp2); // 2
  move_raw(tmp2, y); // 3
  move_raw(tmp1, x); // 4

Imagine that X has a move_raw that leaves its source in an invalid state
and that Y has a move_raw that can throw. Now also imagine line 2
throws. Oops.

> I mean, with the copy-based swap we usually also don't worry about the 
> possibility that one of the copies might throw...

Yes, we do. Read about noexcept.

>> You may decide to provide an easy way for users to opt-in for a memcpy
>> based solution, but that option should only be available only on
>> compilers for which memcpy-ing non-PODs is empirically known to work.
>> And there should be a warning about the non-portability about doing that.
> 
> If you are right and using copy as a fallback for raw moves is not an 
> option, it means a significant loss of generality. 

Like I said, you need to solve the exception safety issues. Look into
noexcept; there may be relief there.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com