move-semantics

If I move-construct a from b , is it still necessary to destruct b , or can I get away without doing so? This question crossed my mind during the implementation of an optional<T> template. Excerpt: ~optional() { if (initialized) { reinterpret_cast<T*>(data)->~T(); } } optional(optional&& o) : initialized(o.initialized) { if (initialized) { new(data) T(std::move(*o)); // move from o.data o.initialized = false; // o.data won't be destructed anymore! } } Of course, I could just replace the bool initialized with a three-valued enumeration that distinguishes between initialized, non-initialized and

I tried to do something like: std::copy(std::make_move_iterator(s1.begin()), std::make_move_iterator(s1.end()), std::make_move_iterator(s2.begin())); And got this error: error: using xvalue (rvalue reference) as lvalue *__result = std::move(*__first); Which seemed confusing to me. The same thing happens if you use std::move . It appears that GCC internally uses a function called std::__copy_move_a which moves rather than copies. Does it matter whether you use std::copy or std::move ? #include <string> #include <iostream> #include <algorithm> #include <iterator> #include <cstring> struct Test {

Rust has the concepts of ownership and borrowing. If a function doesn't borrow its parameter as a reference, the arguments to that function are moved and will be deallocated once they go out of scope. Take this function: fn build_user(email: String, username: String) -> User { User { email: email, username: username, } } This function can be called as: let email = String::from("foo@example.com"); let username = String::from("username"); let user = build_user(email, username); Since email and username have been moved, they can no longer be used after build_user was called. This can be fixed by

This program: #include <iostream> struct T { T() {} T(const T &) { std::cout << "copy constructor "; } T(T &&) { std::cout << "move constructor "; } }; int main() { ([](T t) -> T { return t; })({}); std::cout << '\n'; ([](T t) -> T { return void(), t; })({}); std::cout << '\n'; ([](T t) -> T { return void(), std::move(t); })({}); std::cout << '\n'; } when compiled by gcc-4.7.1 outputs ( link ): move constructor copy constructor move constructor Why does the comma operator have this effect? The standard says: 5.18 Comma operator [expr.comma] 1 - [...] The type and value of the result are the

Due to this bug in Visual Studio 2013 , I need to provide my own move constructor and move assignment for a derived class. However, I don't know how to call the appropriate move functions for the base class. Here's the code: #include <utility> // Base class; movable, non-copyable class shader { public: virtual ~shader() { if (id_ != INVALID_SHADER_ID) { // Clean up } } // Move assignment shader& operator=(shader&& other) { // Brett Hale's comment below pointed out a resource leak here. // Original: // id_ = other.id_; // other.id_ = INVALID_SHADER_ID; // Fixed: std::swap( id_, other.id_ );

Considering the high quality of today's compilers regarding return value optimization (both RVO and NRVO), I was wondering at what class complexity it's actually meaningful to start adding move constructors and move assignment operators. For instance, for this really_trivial class, I just assume that move semantics cannot offer anything more than RVO and NRVO already does when copying around instances of it: class really_trivial { int first_; int second_; public: really_trivial(); ... }; While in this semi_complex class, I'd add a move constructor and move assignment operator without