You define and document for your types what a ‘valid’ state is and what operation can be performed on moved-from objects of your types. Moving an object of a standard library type puts the object into an unspecified state, which can be queried as normal to determine valid operations. 17.6.5.15 Moved-from state of library types … Read more
The implicit generation of move constructors and assignment operators has been contentious and there have been major revisions in recent drafts of the C++ Standard, so currently available compilers will likely behave differently with respect to implicit generation. For more about the history of the issue, see the 2010 WG21 papers list and search for … Read more
From section 17.3.26 of the spec “valid but unspecified state”: an object state that is not specified except that the object’s invariants are met and operations on the object behave as specified for its type [ Example: If an object x of type std::vector<int> is in a valid but unspecified state, x.empty() can be called … 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
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
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
No, that won’t work as intended; you will still get copies. I’m pretty surprised by this, as I’d thought that initializer_list existed to keep an array of temporaries until they were move‘d. begin and end for initializer_list return const T *, so the result of move in your code is T const && — an … Read more
Let’s look at the signature for into_bytes: fn into_bytes(self) -> Vec<u8> This takes self, not a reference to self (&self). That means that self will be consumed and won’t be available after the call. In its place, you get a Vec<u8>. The prefix into_ is a common way of denoting methods like this. I don’t … Read more
Edit: Since @Johannes doesn’t seem to want to post the best solution as an answer, I’ll just do it. #include <iterator> #include <vector> #include <memory> int main(){ using move_only = std::unique_ptr<int>; move_only init[] = { move_only(), move_only(), move_only() }; std::vector<move_only> v{std::make_move_iterator(std::begin(init)), std::make_move_iterator(std::end(init))}; } The iterators returned by std::make_move_iterator will move the pointed-to element when being … 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