rvalue-reference

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? struct foo { foo & operator=( foo const & ) &; foo & operator=( foo && ) &; }; Well, there are certain

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)} // bind to the temporary provided { } }; int main() { S s1{std::vector<int>(5)}; // construct with

Sometimes it's wise to split complicated or long expressions into multiple steps, for example (the 2nd version isn't more clear, but it's just an example): return object1(object2(object3(x))); can be written as: object3 a(x); object2 b(a); object1 c(b); return c; Assuming all 3 classes implement constructors that take rvalue as a parameter, the first version might be faster, because temporary objects are passed and can be moved. I'm assuming that in the 2nd version, the local variables are considered to be lvalues. But if the variables aren't later used, do C++11 compilers optimize the code so

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 operator+(Matrix&& temp, Matrix&& y) { temp += y; return std::move(temp); } Here the std::move is necessary

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 += rhs); } vec&& operator+(const vec& lhs, vec&& rhs) { return move(rhs += lhs); } vec&& operator+(vec&&

I am coding some templated classes for a machine learning library, and I'm facing this issue a lot of times. I'm using mostly the policy pattern, where classes receive as template argument policies for different functionalities, for example: template <class Loss, class Optimizer> class LinearClassifier { ... } The problem is with the constructors. As the amount of policies (template parameters) grows, the combinations of const references and rvalue references grow exponentially. In the previous example: LinearClassifier(const Loss& loss, const Optimizer& optimizer) : _loss(loss), _optimizer