rvalue-reference | 易学教程

Extending temporary's lifetime through rvalue data-member works with aggregate, but not with constructor, why?

阅读更多关于 Extending temporary's lifetime through rvalue data-member works with aggregate, but not with constructor, why?

问题 I've found the following scheme to extend a temporaries lifetime works, I don't know if it should, but it does. struct S { std::vector<int>&& vec; }; int main() { S s1{std::vector<int>(5)}; // construct with temporary std::cout << s1.vec[0] << '\n'; // fine, temporary is alive } However, when S is given an explicit value constructor it is no longer an aggregate, and this scheme fails with an invalid read on s1.vec[0] struct S { std::vector<int>&& vec; S(std::vector<int>&& v) : vec{std::move(v

Should I return an rvalue reference (by std::move'ing)?

阅读更多关于 Should I return an rvalue reference (by std::move'ing)?

问题 A C++Next blog post said that A compute(…) { A v; … return v; } If A has an accessible copy or move constructor, the compiler may choose to elide the copy. Otherwise, if A has a move constructor, v is moved. Otherwise, if A has a copy constructor, v is copied. Otherwise, a compile time error is emitted. I thought I should always return the value without std::move because the compiler would be able to figure out the best choice for users. But in another example from the blog post Matrix

Overloading on R-value references and code duplication

阅读更多关于 Overloading on R-value references and code duplication

问题 Consider the following: struct vec { int v[3]; vec() : v() {}; vec(int x, int y, int z) : v{x,y,z} {}; vec(const vec& that) = default; vec& operator=(const vec& that) = default; ~vec() = default; vec& operator+=(const vec& that) { v[0] += that.v[0]; v[1] += that.v[1]; v[2] += that.v[2]; return *this; } }; vec operator+(const vec& lhs, const vec& rhs) { return vec(lhs.v[0] + rhs.v[0], lhs.v[1] + rhs.v[1], lhs.v[2] + rhs.v[2]); } vec&& operator+(vec&& lhs, const vec& rhs) { return move(lhs +=

Why doesn't C++ move construct rvalue references by default? [duplicate]

阅读更多关于 Why doesn't C++ move construct rvalue references by default? [duplicate]

问题 This question already has an answer here: Rvalue Reference is Treated as an Lvalue? 4 answers Lvalue reference constructor is called instead of rvalue reference constructor 1 answer Say I have the following function void doWork(Widget && param) // param is an LVALUE of RRef type { Widget store = std::move(param); } Why do I need to cast param back to an rvalue with std::move() ? Shouldn't it be obvious that the type of param is rvalue since it was declared in the function signature as an

Why user-defined move-constructor disables the implicit copy-constructor?

阅读更多关于 Why user-defined move-constructor disables the implicit copy-constructor?

While I'm reading boost/shared_ptr.hpp, i saw this code: // generated copy constructor, destructor are fine... #if defined( BOOST_HAS_RVALUE_REFS ) // ... except in C++0x, move disables the implicit copy shared_ptr( shared_ptr const & r ): px( r.px ), pn( r.pn ) // never throws { } #endif What does the comment "generated copy constructor, destructor are fine except in C++11, move disables the implicit copy" mean here? Shall we always write the copy ctor ourselves to prevent this situation in C++11? I've upvoted ildjarn's answer because I found it both accurate and humorous. :-) I'm providing

How to actually implement the rule of five?

阅读更多关于 How to actually implement the rule of five?

UPDATE at the bottom q1: How would you implement the rule of five for a class that manages rather heavy resources, but of which you want it to be passed around by value because that greatly simplifies and beautifies it's usage? Or are not all five items of the rule even needed? In practice, I'm starting something with 3D imaging where an image is usually 128*128*128 doubles. Being able though to write things like this would make the math alot easier: Data a = MakeData(); Data c = 5 * a + ( 1 + MakeMoreData() ) / 3; q2: Using a combination of copy elision / RVO / move semantics the compiler

Rvalue reference: Why aren't rvalues implicitly moved?

阅读更多关于 Rvalue reference: Why aren't rvalues implicitly moved?

问题 On Artima article about C++ rvalue reference (http://www.artima.com/cppsource/rvalue.html) there is words: That's why it is necessary to say move(x) instead of just x when passing down to the base class. This is a key safety feature of move semantics designed to prevent accidently moving twice from some named variable. I can't think situation when such double move can perform. Can you give an example of this? In other words, what will go wrong if all members of T&& would be rvalue references

Operator overload which permits capturing with rvalue but not assigning to

阅读更多关于 Operator overload which permits capturing with rvalue but not assigning to

问题 Is it possible to design and how should I make overloaded operator+ for my class C to have this possible: C&& c = c1 + c2; but this not possible: c1 + c2 = something; Edit: I changed objects to small letters. c1 , c2 and c are objects of class C . && is not the logical operator&& , but rather an rvalue reference. For example writing: double&& d = 1.0 + 2.0; is 100% proper (new) C++ code, while 1.0 + 2.0 = 4.0; is obviously a compiler error. I want exactly the same, but instead for double, for

Should implicitly generated assignment operators be & ref-qualified?

阅读更多关于 Should implicitly generated assignment operators be & ref-qualified?

问题 The following code compiles without problem on gcc 4.8.1: #include <utility> struct foo { }; int main() { foo bar; foo() = bar; foo() = std::move( bar ); } It seems the implicitly generated assignment operators for foo are not & ref-qualified and so can be invoked on rvalues. Is this correct according to the standard? If so, what reason is there for not requiring implicitly generated assignment operators to be & ref-qualified? Why doesn't the standard require the following to be generated?

Should a move constructor take a const or non-const rvalue reference?

阅读更多关于 Should a move constructor take a const or non-const rvalue reference?

问题 In several places I've seen the recommended signatures of copy and move constructors given as: struct T { T(); T(const T& other); T(T&& other); }; Where the copy constructor takes a const reference, and the move constructor takes a non-const rvalue reference. As far as I can see though, this prevents me taking advantage of move semantics when returning const objects from a function, such as in the case below: T generate_t() { const T t; return t; } Testing this with VC11 Beta, T 's copy