Re: [boost] [variant] Please vote for behavior

Subject: Re: [boost] [variant] Please vote for behavior
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-02-07 21:57:15

on Thu Feb 07 2013, Michael Marcin <mike.marcin-AT-gmail.com> wrote:

> Sebastian Redl wrote:
>>
>> On 07.02.2013, at 21:25, Dave Abrahams wrote:
>>
>>>
>>> on Thu Feb 07 2013, Sebastian Redl <sebastian.redl-AT-getdesigned.at> wrote:
>
>>>
>>>> On 06.02.2013, at 22:10, Dave Abrahams wrote:
>>>>
>>>>>
>>>>> on Sat Feb 02 2013, Sebastian Redl <sebastian.redl-AT-getdesigned.at> wrote:
>>>>>
>>>>>> Anything that gives the target object the state the source object had
>>>>>> and is cheaper than a copy is a successful move, really. That is what
>>>>>> a move ultimately is: an optimization of copying.
>>>>>
>>>>> I never liked that characterization.  If move were an optimization of
>>>>> copy it would have all the semantics of copy...
>>>>
>>>> I disagree. That would be the case if move were a universally
>>>> applicable optimization, but it isn't. It's a special case
>>>> optimization. In intent, it optimizes copying for the case where the
>>>> resulting state of the source object is irrelevant. In practice, the
>>>> source object must retain some valid state.
>>>>
>>>> This is really similar to how the compiler can only apply some
>>>> optimizations if it can prove certain properties of the code,
>>>> e.g. that two pointers don't alias (various redundant load or store
>>>> eliminations) or that a piece of code is side effect free (loop
>>>> fusion, common subexpression elimination).
>>>
>>> Yes, but those are semantics-preserving transformations.  I suppose you
>>> can call move an optimization if you presume the irrelevancy of the
>>> source object has been proven, but usually that proof is part of the
>>> optimization process.
>>
>> That's why move only implicitly kicks in for rvalues and return of
>> local lvalues, where this has indeed been proven. (Sort of. It's
>> actually not true for local lvalues, but then, copy elision can
>> change visible behavior too.)
>> For lvalues, where the compiler can't (or won't) prove it, user
>> intervention is required in the form of std::move. Think of it like
>> of the restrict qualifier for aliasing.
>
> I don't see how move is an optimization of copy since you can move
> noncopyable types.

Yeah, that's another thing.

-- 
Dave Abrahams