rvalue-reference

I want to make clear that the constructor of my class A will take ownership of the passed Data parameter. The obvious thing to do is take a unique_ptr by value: class A { public: A(std::unique_ptr<Data> data) : _data(std::move(data)) { } std::unique_ptr<Data> _data; }; However, for my use-case, there is no reason why Data should be a pointer, since a value type would suffice. The only remaining option that I could think of to make really clear that Data will be owned by A is pass by rvalue-reference: class A { public: A(Data&& data) : _data(std::move(data)) { } Data _data; }; Is this a valid

I tested the following code with GCC, Clang, ICC and VS: void f() {} void g(void (&&)()) { } int main() { g(f); } As we can see, g takes an rvalue reference but f is an lvalue and, in general, rvalue references cannot be bound to lvalues. That's exactly what ICC complains about: error: an rvalue reference cannot be bound to an lvalue VS also gives an error but for another reason: error C2664: 'void h(void (__cdecl &&)(void))' : cannot convert parameter 1 from 'void (__cdecl *)(void)' to 'void (__cdecl &&)(void)' This suggests to me that VS is immediately performing a function-to-pointer

struct STest : public boost::noncopyable { STest(STest && test) : m_n( std::move(test.m_n) ) {} explicit STest(int n) : m_n(n) {} int m_n; }; STest FuncUsingConst(int n) { STest const a(n); return a; } STest FuncWithoutConst(int n) { STest a(n); return a; } void Caller() { // 1. compiles just fine and uses move ctor STest s1( FuncWithoutConst(17) ); // 2. does not compile (cannot use move ctor, tries to use copy ctor) STest s2( FuncUsingConst(17) ); } The above example illustrates how in C++11, as implemented in Microsoft Visual C++ 2012, the internal details of a function can modify its

In this article http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/comment-page-1/#comment-1877 : T& T::operator=(T const& x) // x is a reference to the source { T tmp(x); // copy construction of tmp does the hard work swap(*this, tmp); // trade our resources for tmp's return *this; // our (old) resources get destroyed with tmp } but in light of copy elision, that formulation is glaringly inefficient! It’s now “obvious” that the correct way to write a copy-and-swap assignment is: T& operator=(T x) // x is a copy of the source; hard work already done { swap(*this, x); // trade our