rvalue-reference | 易学教程

Overload resolution between object, rvalue reference, const reference

阅读更多关于 Overload resolution between object, rvalue reference, const reference

Given all three functions, this call is ambiguous. int f( int ); int f( int && ); int f( int const & ); int q = f( 3 ); Removing f( int ) causes both Clang and GCC to prefer the rvalue reference over the lvalue reference. But instead removing either reference overload results in ambiguity with f( int ) . Overload resolution is usually done in terms of a strict partial ordering, but int seems to be equivalent to two things which are not equivalent to each other. What are the rules here? I seem to recall a defect report about this. Is there any chance int && may be preferred over int in a future

Should I std::move a shared_ptr in a move constructor?

阅读更多关于 Should I std::move a shared_ptr in a move constructor?

问题 Consider: #include <cstdlib> #include <memory> #include <string> #include <vector> #include <algorithm> #include <iterator> using namespace std; class Gizmo { public: Gizmo() : foo_(shared_ptr<string>(new string("bar"))) {}; Gizmo(Gizmo&& rhs); // Implemented Below private: shared_ptr<string> foo_; }; /* // doesn't use std::move Gizmo::Gizmo(Gizmo&& rhs) : foo_(rhs.foo_) { } */ // Does use std::move Gizmo::Gizmo(Gizmo&& rhs) : foo_(std::move(rhs.foo_)) { } int main() { typedef vector<Gizmo>

Perfect forwarding a member of object

阅读更多关于 Perfect forwarding a member of object

问题 Suppose I have two struct s: struct X {}; struct Y { X x; } I have functions: void f(X&); void f(X&&); How do I write a function g() that takes Y& or Y&& but perfect forwarding X& or X&& to f() , respectively: template <typename T> void g(T&& t) { if (is_lvalue_reference<T>::value) { f(t.x); } else { f(move(t.x)); } } The above code illustrate my intention but is not very scalable as the number of parameters grows. Is there a way make it work for perfect forwarding and make it scalable? 回答1:

Preventing non-const lvalues from resolving to rvalue reference instead of const lvalue reference

阅读更多关于 Preventing non-const lvalues from resolving to rvalue reference instead of const lvalue reference

问题 I'm having trouble overloading a function to take a value either by const reference or, if it is an rvalue, an rvalue reference. The problem is that my non-const lvalues are binding to the rvalue version of the function. I'm doing this in VC2010. #include <iostream> #include <vector> using namespace std; template <class T> void foo(const T& t) {cout << "void foo(const T&)" << endl;} template <class T> void foo(T&& t) {cout << "void foo(T&&)" << endl;} int main() { vector<int> x; foo(x); //

Should I write constructors using rvalues for std::string?

阅读更多关于 Should I write constructors using rvalues for std::string?

问题 I have a simple class: class X { std::string S; X (const std::string& s) : S(s) { } }; I've read a bit about rvalues lately, and I've been wondering, if I should write constructor for X using rvalue, so I would be able do detect temporary objects of std::string type? I think it should look something like: X (std::string&& s) : S(s) { } As to my knowledge, implementation of std::string in compilers supporting C++11 should use it's move constructor when available. 回答1: X (std::string&& s) : S(s

Why does C++11 have implicit moves for value parameters, but not for rvalue parameters?

阅读更多关于 Why does C++11 have implicit moves for value parameters, but not for rvalue parameters?

问题 In C++11, value parameters (and other values) enjoy implicit move when returned: A func(A a) { return a; // uses A::A(A&&) if it exists } At least in MSVC 2010, rvalue reference parameters need std::move : A func(A && a) { return a; // uses A::A(A const&) even if A::A(A&&) exists } I would imagine that inside functions, an rvalue reference and a value behave similar, with the only difference that in case of values, the function itself is responsible for destruction, while for rvalue

Is the pass-by-value-and-then-move construct a bad idiom?

阅读更多关于 Is the pass-by-value-and-then-move construct a bad idiom?

Since we have move semantics in C++, nowadays it is usual to do void set_a(A a) { _a = std::move(a); } The reasoning is that if a is an rvalue, the copy will be elided and there will be just one move. But what happens if a is an lvalue? It seems there will be a copy construction and then a move assignment (assuming A has a proper move assignment operator). Move assignments can be costly if the object has too many member variables. On the other hand, if we do void set_a(const A& a) { _a = a; } There will be just one copy assignment. Can we say this way is preferred over the pass-by-value idiom

How would one call std::forward on all arguments in a variadic function?

阅读更多关于 How would one call std::forward on all arguments in a variadic function?

问题 I was just writing a generic object factory and using the boost preprocessor meta-library to make a variadic template (using 2010 and it doesn't support them). My function uses rval references and std::forward to do perfect forwarding and it got me thinking...when C++0X comes out and I had a standard compiler I would do this with real variadic templates. How though, would I call std::forward on the arguments? template <typename ...Params> void f(Params... params) // how do I say these are

Can I typically/always use std::forward instead of std::move?

阅读更多关于 Can I typically/always use std::forward instead of std::move?

I've been watching Scott Meyers' talk on Universal References from the C++ and Beyond 2012 conference, and everything makes sense so far. However, an audience member asks a question at around 50 minutes in that I was also wondering about. Meyers says that he does not care about the answer because it is non-idiomatic and would silly his mind, but I'm still interested. The code presented is as follows: // Typical function bodies with overloading: void doWork(const Widget& param) // copy { // ops and exprs using param } void doWork(Widget&& param) // move { // ops and exprs using std::move(param)

Why do some people use swap for move assignments?

阅读更多关于 Why do some people use swap for move assignments?

For example, stdlibc++ has the following: unique_lock& operator=(unique_lock&& __u) { if(_M_owns) unlock(); unique_lock(std::move(__u)).swap(*this); __u._M_device = 0; __u._M_owns = false; return *this; } Why not just assign the two __u members to *this directly? Doesn't the swap imply that __u is assigned the *this members, only to later have then assigned 0 and false... in which case the swap is doing unnecessary work. What am I missing? (the unique_lock::swap just does an std::swap on each member) It's my fault. (half-kidding, half-not). When I first showed example implementations of move