In the case of return std::move(foo); the move is superfluous because of 12.8/32: When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select … Read more
17.6.5.15 [lib.types.movedfrom] Objects of types defined in the C++ standard library may be moved from (12.8). Move operations may be explicitly specified or implicitly generated. Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state. When an object is in an unspecified state, you can perform any operation on the … Read more
The only advantage I can see is when the sequence iterator returns a proxy reference and you need to operate on that reference in a non-const way. For example consider: #include <vector> int main() { std::vector<bool> v(10); for (auto& e : v) e = true; } This doesn’t compile because rvalue vector<bool>::reference returned from the … Read more
Assuming that create and destroy are free functions (which seems to be the case from the OP’s code snippet) with the following signatures: Bar* create(); void destroy(Bar*); You can write your class Foo like this class Foo { std::unique_ptr<Bar, void(*)(Bar*)> ptr_; // … public: Foo() : ptr_(create(), destroy) { /* … */ } // … … Read more
I think that the one thing the other answers did not emphasize enough is the point of speed. std::shared_ptr reference count is atomic. increasing or decreasing the reference count requires atomic increment or decrement. This is hundred times slower than non-atomic increment/decrement, not to mention that if we increment and decrement the same counter we … Read more
I am aware of 5 general categories where recompiling a C++03 compiler as C++11 can cause unbounded performance increases that are practically unrelated to quality of implementation. These are all variations of move semantics. std::vector reallocate struct bar{ std::vector<int> data; }; std::vector<bar> foo(1); foo.back().data.push_back(3); foo.reserve(10); // two allocations and a delete occur in C++03 every … Read more
First, “ref-qualifiers for *this” is a just a “marketing statement”. The type of *this never changes, see the bottom of this post. It’s way easier to understand it with this wording though. Next, the following code chooses the function to be called based on the ref-qualifier of the “implicit object parameter” of the function†: // … Read more
First example std::vector<int> return_vector(void) { std::vector<int> tmp {1,2,3,4,5}; return tmp; } std::vector<int> &&rval_ref = return_vector(); The first example returns a temporary which is caught by rval_ref. That temporary will have its life extended beyond the rval_ref definition and you can use it as if you had caught it by value. This is very similar to … Read more
1. “What is it?” While std::move() is technically a function – I would say it isn’t really a function. It’s sort of a converter between ways the compiler considers an expression’s value. 2. “What does it do?” The first thing to note is that std::move() doesn’t actually move anything. It changes an expression from being … Read more
In addition to what visitor said : The function void emplace_back(Type&& _Val) provided by MSCV10 is non conforming and redundant, because as you noted it is strictly equivalent to push_back(Type&& _Val). But the real C++0x form of emplace_back is really useful: void emplace_back(Args&&…); Instead of taking a value_type it takes a variadic list of arguments, … Read more