move-semantics

Is there a reason when a function should return a RValue Reference ? A technique, or trick, or an idiom or pattern? MyClass&& func( ... ); I am aware of the danger of returning references in general, but sometimes we do it anyway, don't we ( T& T::operator=(T) is just one idiomatic example). But how about T&& func(...) ? Is there any general place where we would gain from doing that? Probably different when one writes library or API code, compared to just client code? There are a few occasions when it is appropriate, but they are relatively rare. The case comes up in one example when you want

I know that it's a very old debate that has already been discussed many times all over the world. But I'm currently having troubles deciding which method I should use rather than another between static and dynamic arrays in a particular case. Actually, I woudn't have used C++11, I would have used static arrays. But I'm now confused since there could be equivalent benefits with both. First solution: template<size_t N> class Foo { private: int array[N]; public: // Some functions } Second solution: template<size_t N> class Foo { private: int* array; public: // Some functions } I can't happen to

I was expecting that std::make_move_iterator will always move contents, but it seems not. It looks like it is moving elements in vector<string> but not in vector<int> . See the below code snippet: #include <iostream> #include <iterator> #include <string> #include <vector> void moveIntVector() { std::cout << __func__ << std::endl; std::vector<int> v1; for (unsigned i = 0; i < 10; ++i) { v1.push_back(i); } std::vector<int> v2( std::make_move_iterator(v1.begin() + 5), std::make_move_iterator(v1.end())); std::cout << "v1 is: "; for (auto i : v1) { std::cout << i << " "; } std::cout << std::endl;

Here's a very easy way to define move assignment for most any class with a move constructor: class Foo { public: Foo(Foo&& foo); // you still have to write this one Foo& operator=(Foo&& foo) { if (this != &foo) { // avoid destructing the only copy this->~Foo(); // call your own destructor new (this) Foo(std::move(foo)); // call move constructor via placement new } return *this; } // ... }; Is this sequence of calling your own destructor followed by placement new on the this pointer safe in standard C++11? Only if you never, ever derive a type from this class. If you do, this will turn the

I have some non-copyable type and a function that consumes and (maybe) produces it: type Foo = Vec<u8>; fn quux(_: Foo) -> Option<Foo> { Some(Vec::new()) } Now consider a type that is somehow conceptually very similar to Box : struct NotBox<T> { contents: T } We can write a function that temporarily moves out contents of the NotBox and puts something back in before returning it: fn bar(mut notbox: NotBox<Foo>) -> Option<NotBox<Foo>> { let foo = notbox.contents; // now `notbox` is "empty" match quux(foo) { Some(new_foo) => { notbox.contents = new_foo; // we put something back in Some(notbox) }

I'm looking for a method that consumes a Vec and returns one element, without the overhead of restoring Vec 's invariants the way remove and swap_remove do: fn take<T>(vec: Vec<T>, index: usize) -> Option<T> However, I can't find such a method. Am I missing something? Is this actually unsafe or impossible? This is a different question from Built in *safe* way to move out of Vec<T>? There the goal was a remove method that didn't panic on out of bounds access and returned a Result . I'm looking for a method that consumes a Vec and returns one of the elements. None of the answers to the above

I have a function that operates on a big chunk of data passed in as a sink argument. My BigData type is already C++11-aware and comes with fully functional move constructor and move assignment implementations, so I can get away without having to copy the damn thing: Result processBigData(BigData); [...] BigData b = retrieveData(); Result r = processBigData(std::move(b)); This all works perfectly fine. However, my processing function may fail occasionally at runtime resulting in an exception. This is not really a problem, since I can just fix stuff and retry: BigData b = retrieveData(); Result

After reading this recent question by @Mehrdad on which classes should be made non-movable and therefore non-copyable , I starting wondering if there are use cases for a class which can be copied but not moved . Technically, this is possible: struct S { S() { } S(S const& s) { } S(S&&) = delete; }; S foo() { S s1; S s2(s1); // OK (copyable) return s1; // ERROR! (non-movable) } Although S has a copy constructor, it obviously does not model the CopyConstructible concept, because that is in turn a refinement of the MoveConstructible concept, which requires the presence of a (non-deleted) move

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