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

Subject: Re: [boost] [variant] Please vote for behavior
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2013-02-07 22:32:21

On Thu, Feb 7, 2013 at 6:57 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>
> 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.

Is the compiler even allowed to choose between copy and move? My
understanding is that you can't tell it "this type can't be copied so
if I've told you to copy, see if you can move instead".

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode