On Wednesday, 10 February 2016 at 20:42:29 UTC, w0rp wrote:
Back on the original topic, Scott Meyers often says "std::move
doesn't move." It's more like std::rvalue_cast. C++ uses
r-value references in order to be able to rip the guts out of
objects and put them into other objects.
Well. In C++ "std::move(x)" is just a "static_cast<T&&>(x)" for
"T x".
"T&&" references are different from "T&" by acting like T&
references when used, but not on overloads. They are primarily
for distinguishing between overloads on temporaries in function
calls, T&& binds to temporaries. So you use "std::move(x)" to
tell the type system that you want it to be cast as a references
to a temporary like reference (or rvalue reference).
So that's why constructors with "T&&" are called move
constructors (taking stuff from temporaries) and "const T&" are
called copy constructors (assuming that the parameter might have
a long life on it's own).
That kind of return value optimisation was the original
motivation for r-value references, for when C++98 RVO isn't
good enough, from my understanding.
It is for overloading. Why allocate lots of stuff by copying it
if you know that the referenced object is about to die anyway? If
it is dying we just steal the stuff it is holding.
stack.push(string("hiii")) // we could steal this stuff
string x("hiii")
stack.push(x) // we have to copy this stuff
Maybe someone else will correct me on a point or two there, but
that's the understanding of move semantics in D that I have had.
I don't think D has move semantics... It does copying and
clearing... The postblit thing looks like a dirty hack to me.
