rvalue

I'm wondering the best form for my constructors. Here is some sample code: class Y { ... } class X { public: X(const Y& y) : m_y(y) {} // (a) X(Y y) : m_y(y) {} // (b) X(Y&& y) : m_y(std::forward<Y>(y)) {} // (c) Y m_y; } Y f() { return ... } int main() { Y y = f(); X x1(y); // (1) X x2(f()); // (2) } From what I understand, this is the best the compiler can do in each situation. (1a) y is copied into x1.m_y (1 copy) (1b) y is copied into the argument of the constructor of X, and then copied into x1.m_y (2 copies) (1c) y is moved into x1.m_y (1 move) (2a) result of f() is copied into x2.m_y (1

I have heard Scott Meyers say " std::move() doesn't move anything" ... but I haven't understood what it means. So to specify my question consider the following: class Box { /* things... */ }; Box box1 = some_value; Box box2 = box1; // value of box1 is copied to box2 ... ok What about: Box box3 = std::move(box1); I do understand the rules of lvalue and rvalue but what I don't understand is what is actually happening in the memory? Is it just copying the value in some different way, sharing an address or what? More specifically: what makes moving faster than copying? I just feel that

I know that const reference prolongs the life of a temporary locally. Now I am asking myself if this propriety can be extended on a chain of temporary objects, that is, if I can safely define: std::string const& foo = aBar.getTemporaryObject1().getTemporaryObject2(); My feeling is that, since the the first method aBar.getTemporaryObject1() returns already a temporary object, the propriety doesn't hold for aBar.getTemporaryObject2() . The lifetime extension only applies when a reference is directly bound to that temporary. For example, initializing another reference from that reference does not

The High Integrity C++ Standards suggest that rvalue arguments to functions can be deleted thus preventing implicit conversions. http://www.codingstandard.com/rule/8-3-4-define-delete-functions-with-parameters-of-type-rvalue-reference-to-const/ I've found that the behaviour for primitives and user-defined types is very different. struct A { }; struct B { B(const A& ) {} }; template <class T> void foo(const T&&) = delete; // 1 - deleted rvalue overload. const intentional. void foo(B) {} // 2 void foo(int) {} // 3 int main(int argc, char* argv[]) { A a; foo(a); // This resolves to 2 foo(3.3); //

Some time ago I was confused by the following behavior of some code when I wanted to write a is_callable<F, Args...> trait. Overload resolution won't call functions accepting arguments by non-const ref, right? Why doesn't it reject in the following because the constructor wants a Test& ? I expected it to take f(int) ! struct Test { Test() { } // I want Test not be copyable from rvalues! Test(Test&) { } // But it's convertible to int operator int() { return 0; } }; void f(int) { } void f(Test) { } struct WorksFine { }; struct Slurper { Slurper(WorksFine&) { } }; struct Eater { Eater(WorksFine)

If I have, void foo(Bar c); void foo(Bar&& c); foo(Bar()); why is the call to 'foo' is ambiguous? Isn't Bar() in the foo argument clearly an rValue? Binding to a reference is an "exact match", as is binding to a non-reference, so both overloads are equally good. In Standardese, this is 13.3.3.1.4 ("Reference binding", [over.ics.ref]): When a parameter of reference type binds directly (8.5.3) to an argument expression, the implicit conversion sequence is the identity conversion [...] 来源： https://stackoverflow.com/questions/36696312/why-is-pass-by-value-and-pass-by-rvalue-overload-c-function

In the following example: class A { private: double content; public: A():content(0) {} A operator+(const A& other) { content += other.content; return *this; } void operator=(const A& other) { content = other.content; } }; A is a simple wrapper for a double for which the + and = operators have been overloaded. In the following use: int main(int argc, char *argv[]) { A a, b, c; (a+b) = c ; // Why is this operation legal? } Why does (a+b) = c compile? I would like to know why this statement is legal, because the result of (a+b) must be an rvalue . I am not returning a reference from operator+ .