rvalue-reference

I am currently trying to figure out how to do move semantics correctly with an object which contains a pointer to allocated memory. I have a big datastructure, which contains an internal raw pointer to the actual storage (for efficiency reasons). Now I added a move constructor and move operator=() . In these methods I am std::move() ing the pointer to the new structure. However I am not sure what to do with the pointer from the other structure. Here is a simple example of what I am doing: class big_and_complicated { // lots of complicated code }; class structure { public: structure() : m_data(

template<class U> void f( U && v) { std::cout << typeid(v).name() << "\n"; //'int' in both cases if( boost::is_same<int&&,U>::value ) { std::cout << "reach here\n"; //only with f<int&&>(int(1)); } } int main() { f(int(1)); f<int&&>(int(1)); std::cin.ignore(); } Why v parameter is interpreted as int when I don't explicitly use f<int&&> ? What is the difference ? (Compiled with MVS2010) My guess is that First is passed as a rvalue and second as a rvalue reference and both bound correctly into a rvalue reference, am I right ? Thanks. Dietmar Kühl No, not really. An rvalue reference is never

Many people do not know that const rvalue references are part of the C++11 language. This blog post discusses them but appears to be mistaken regarding the binding rules. Quoting the blog: struct s {}; void f ( s&); // #1 void f (const s&); // #2 void f ( s&&); // #3 void f (const s&&); // #4 const s g (); s x; const s cx; f (s ()); // rvalue #3, #4, #2 f (g ()); // const rvalue #4, #2 f (x); // lvalue #1, #2 f (cx); // const lvalue #2 Note the asymmetry: while a const lvalue reference can bind to an rvalue, a const rvalue reference cannot bind to an lvalue. In particular, this makes a const

I wonder if there is any way to differentiate the function calls (with arrays as parameters) shown in the following code: #include <cstring> #include <iostream> template <size_t Size> void foo_array( const char (&data)[Size] ) { std::cout << "named\n"; } template <size_t Size> void foo_array( char (&&data)[Size] ) //rvalue of arrays? { std::cout << "temporary\n"; } struct A {}; void foo( const A& a ) { std::cout << "named\n"; } void foo( A&& a ) { std::cout << "temporary\n"; } int main( /* int argc, char* argv[] */ ) { A a; const A a2; foo(a); foo(A()); //Temporary -> OK! foo(a2); //----------

//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

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

Suppose that I have a function A f() ; I want to initialize a local variable a to the return value of f ; I don't want to rely on RVO; What is the best option (and why) to avoid the return value of f being copied when a may have to be modified I know that a will not be modified Options: a) A a = f(); b) A&& a = f(); c) const A& = f(); d) const A&& = f(); EDIT: I would say: b) c) Because both use references and avoid an extra copy (which could be avoided by RVO as well, but that is not guaranteed). So how come I see option a) suggested most of the time? I guess the heart of the question is: I