On Saturday, 13 February 2016 at 09:11:06 UTC, Lars T.
Kyllingstad wrote:
In my experience, in the vast majority of cases a C++ move
operation boils down to a memberwise copy (of value types) or
copy-and-reset (of reference types). With the extra logic and
program flow that is sometimes involved in move construction
and move assignment, I suspect that a straightforward double
memcpy as it is done in D will be almost as performant or
moreso most of the time.
No? Not in the libraries I write. A move typically just means
copying 1-4 64 bit values and setting a single 64 bit value in
the source. Usually written as an inline function.
Or nothing, in the case where the logic does not end up with a
move, something which D cannot represent with the same semantic
distinction.
Add to that the fact that a lot of programmers out there will
implement move construction in terms of move assignment --
which makes it a default construction PLUS move -- and move
assignment in terms of swap -- i.e., three moves -- for the
sake of DRY.
Huh? Move assignments is no different from move construction,
except you have to release the existing value if the receiving
object isn't empty. Constructing an empty resource owner object
usually just means setting a single field to zero, which is
inlined and removed if it is followed by an assignment.
Personally, I think D's move semantics are actually clearer
and easier to get right.
But I don't think D has move semantics. I don't think it makes
for correctness for resource ownership.
explain to newbies: If you use std.move() on something it
definitely gets moved. In C++, if you use std::move() on
something it may or may not be moved; it depends on the
recipient of the move.
No? With D's std.move() the resource can be destroyed or get into
an inconsistent state if the caller does it wrong? Or can the
type system help you?
