move-semantics

//code from https://skillsmatter.com/skillscasts/2188-move-semanticsperfect-forwarding-and-rvalue-references class Widget { public: Widget(Widget&& rhs) : pds(rhs.pds) // take source’s value { rhs.pds = nullptr; // why?? } private: struct DataStructure; DataStructure *pds; }; I can't understand the reason for setting rhd.pds to nullptr . What will happen if we remove this line : rhs.pds = nullptr; Joseph Mansfield Some details of the class have been removed. In particular, the constructor dynamically allocates the DataStructure object and the destructor deallocates it. If, during a move, you

Example code : int main() { std::vector<int> v1{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; std::cout << "Printing v1" << std::endl; print(v1); std::vector<int> v2(std::make_move_iterator(v1.begin()), std::make_move_iterator(v1.end())); std::cout << "Printing v1" << std::endl; print(v1); std::cout << "Printing v2" << std::endl; print(v2); std::vector<std::string> v3{"some", "stuff", "to", "put", "in", "the", "strings"}; std::cout << "Printing v3" << std::endl; print(v3); std::vector<std::string> v4(std::make_move_iterator(v3.begin()), std::make_move_iterator(v3.end())); std::cout << "Printing v3" << std:

Is there any point implementing a move constructor and move assignment operator for a struct or class that contains only primitive types? For instance, struct Foo { float x; float y; float z; /// ... ctor, copy ctor, assignment overload, etc... }; I can see that, if I had something more complex, like: struct Bar { float x,y,z; std::string Name; }; where I'd rather move Name than copy it, a move ctor would make sense. However, "moving" a float doesn't (semantically) make sense to me. Thoughts? Joseph Mansfield Even if you have that std::string member, it doesn't make sense to implement a move

Consider the following: struct X { Y y_; X(const Y & y) :y_(y) {} X(Y && y) :y_(std::move(y)) {} }; Is it necessary to define a constructor like the second one in order to take full advantage of move semantics? Or will it be taken care of automatically in the appropriate situations? Yes, but no. Your code should just be this: struct X { Y y_; X(Y y) : // either copy, move, or elide a Y y_(std::move(y)) // and move it to the member {} }; If you ever say in design "I need my own copy of this data"*, then you should just take the argument by value and move it to where it needs to be. It isn't

Are std::vector<double> foo () { std::vector<double> t; ... return t; } and std::vector<double> foo () { std::vector<double> t; ... return std::move (t); } equivalent ? More precisely, is return x always equivalent to return std::move (x) ? They're not equivalent, and you should always use return t; . The longer version is that if and only if a return statement is eligible for return value optimization, then the returnee binds to rvalue reference (or colloquially, "the move is implicit"). By spelling out return std::move(t); , however, you actually inhibit return value optimization! 来源： https:

Hi I created a class Foo with a noexcept move constructor using gcc 4.7 and set the vector reserve size to 2 so that it would have to reallocate the size when adding the 3rd item. It seems it is calling the copy constructor instead of the move constructor when doing this. Am I missing something here? #include <vector> #include <iostream> class Foo { public: Foo(int x) : data_(x) { std::cout << " constructing " << std::endl; } ~Foo() { std::cout << " destructing " << std::endl; } Foo& operator=(const Foo&) = default; Foo& operator=(Foo&&) = default; Foo(Foo&& other) noexcept : data_(std::move

There is a great example of Rust's move semantics documented here: Rust Move Semantics on the Rust By Example website. I have a basic understanding of both cases demonstrated. The first being how a primitive can have a new alias and the original can still be used because the end result is a copy seeing as i32 utilizes the Copy trait. This makes good sense to me. Additionally, for many good reasons the second example makes sense in terms of having multiple aliases that refer to an i32 on the heap. Rust enforces ownership rules and therefore the original alias cannot be used now that a new

The standard library policy about move assignment is that the implementation is allowed to assume that self-assignment will never happen ; this seems to me a really bad idea, given that: the "regular" ("copy") assignment contract in C++ has always been regarded as safe against self-assignment; now we have yet another incoherent corner case of C++ to remember and to explain - and a subtly dangerous one, too; I think we all agree that what is needed in C++ is not more hidden traps; it complicates algorithms - anything in the remove_if family need to take care of this corner case; it would be