Consider this code:
#include <iostream> using namespace std; void Func(int&& i) { ++i; } int main() { int num = 1234; cout << "Before: " << num << endl; Func(std::move(num)); cout << "After: " << num << endl; }
Its output is:
Before: 1234 After: 1235
Clearly, i
is being modified inside Func
, as it is bound to parameter i
after being "converted" to an r-value reference by std::move
.
Well, my point:
Moving an object means transferring ownership of resources from one object into another. However, built-in types holds no resources because they themselves are the resources. It makes no sense to transfer the resources they hold. As shown by the example, num
's value is modified. Its resource, its self, is the one being modified.
Do built-in types have move semantics?
Also, Do built-in type objects after it is moved (if it is) a well-defined behavior?
Move semantics allows you to avoid unnecessary copies when working with temporary objects that are about to evaporate, and whose resources can safely be taken from that temporary object and used by another.
Move semantics aim to avoid the copying of data from temporary objects by instead stealing the memory location of where the object resides. This behaviour is implemented through the use of a move constructor and move assignment operator that act only on rvalue references.
Is specializing std::swap deprecated now that we have move semantics? No. This is the generic version, but you can optimize it to skip a third move operation.
If a copy constructor, copy-assignment operator, move constructor, move-assignment operator, or destructor is explicitly declared, then: No move constructor is automatically generated. No move-assignment operator is automatically generated.
And so, is the one shown by the example a well-defined behavior?
Yes, the behaviour shown in the example is the only behaviour allowed by the standard. That is because std::move
doesn't move. The things that move are move constructors and move assignment operators.
All std::move
does is change an lvalue into an xvalue, so that it can bind to rvalue references. It does not invoke any constructor or anything else. Changing the value category happens at the type level. Nothing happens at runtime.
Rvalue references are still references: they refer to the original object. The function increments the original integer through the reference given.
If a function takes an argument by reference, no copies nor moves happen: the original object is bound to the reference.
If a function takes an argument by value, then we might have a move.
However, fundamental types don't have move constructors. Moves degrade to copies in that case.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With