Every expression is one, and only one, of: lvalue xvalue prvalue The union of expressions that are lvalues and xvalues are known collectively as glvalues. The union of expressions that are xvalues and prvalues are known collectively as rvalues. Thus xvalue expressions are known both as glvalues and rvalues. The handy diagram found in Alf‘s … Read more
The committee already seems to be aware that there’s a problem in this part of the standard. CWG issue 690 talks about a somewhat similar problem with exactly the same part of the standard (in the “additional note” from September, 2009). I’d guess new language will be drafted for that part of the standard soon. … Read more
In a class that provides reference-getters, ref-qualifier overloading can activate move semantics when extracting from an rvalue. E.g.: class some_class { huge_heavy_class hhc; public: huge_heavy_class& get() & { return hhc; } huge_heavy_class const& get() const& { return hhc; } huge_heavy_class&& get() && { return std::move(hhc); } }; some_class factory(); auto hhc = factory().get(); This does … Read more
I’ve upvoted ildjarn’s answer because I found it both accurate and humorous. 🙂 I’m providing an alternate answer because I’m assuming because of the title of the question that the OP might want to know why the standard says so. background C++ has implicitly generated copy members because if it didn’t, it would’ve been still-born … Read more
You’ve missed a significant optimization in your copy assignment operator. And subsequently the situation has gotten confused. AnObject& operator = ( const AnObject& rh ) { if (this != &rh) { if (n != rh.n) { delete [] a; n = 0; a = new int [ rh.n ]; n = rh.n; } std::copy(rh.a, rh.a+n, … Read more
Expensive-to-move types are rare in modern C++ usage. If you are concerned about the cost of the move, write both overloads: void set_a(const A& a) { _a = a; } void set_a(A&& a) { _a = std::move(a); } or a perfect-forwarding setter: template <typename T> void set_a(T&& a) { _a = std::forward<T>(a); } that will … Read more
The things that are automatically treated as rvalues are things without names, and things that (very shortly) will not have a name (in the return value case). T&& t has a name, it is t. The reason why rvalues are those things is that referring to them after that point of use is next to … Read more
A universal reference such as T&& can deduce T to be an “object type“, or a “reference type“ In your example it can deduce T as int when passed an rvalue, so the function parameter is int&&, or it can deduce T as int& when passed an lvalue, in which case the function parameter is … Read more
What are the rules here? As there is only one parameter, the rule is that one of the three viable parameter initializations of that parameter must be a better match than both the other two. When two initializations are compared, either one is better than the other, or neither is better (they are indistinguishable). Without … Read more
It is correct that std::move(x) is just a cast to rvalue – more specifically to an xvalue, as opposed to a prvalue. And it is also true that having a cast named move sometimes confuses people. However the intent of this naming is not to confuse, but rather to make your code more readable. The … Read more