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