Given that in Rust (unlike C or C++) the address of a value is not considered to matter, there is nothing in terms of language that prevents the elision of the copy. However, today rustc does not optimize anything: all optimizations are delegated to LLVM, and it seems you have hit a limitation of the … Read more
rval is not a Rvalue. It is an Lvalue inside the body of the move constructor. That’s why we have to explicitly invoke std::move. Refer this. The important note is Note above that the argument x is treated as an lvalue internal to the move functions, even though it is declared as an rvalue reference … Read more
On the usefulness of const&&… (in general) The usefulness of the const&& qualifier on the member method is minimal at best. The object cannot be modified in the same manner as a && method would allow it to be modified; it is const after all (as noted, mutable does change this). So we will not … Read more
It is a matter of judgment. I will typically let std::swap do the job for prototyping code, but for release code write a custom swap. I can usually write a custom swap that is about twice as fast as 1 move construction + 2 move assignments + 1 resourceless destruction. However one may want 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
The book says the for loop took ownership of v1_iter and made it mutable behind the scenes, Exactly, and one can make an even simpler example: let v = vec![1,2,3]; let mut x = v; x.push(0); Note that v and x are separate variable bindings: for as long as the variable v retained our 3-element … Read more
explicit Trade(vecstr_t&& vec) : _vec(vec) {} In the constructor above, even though vec is of type rvalue reference to vecstr_t, it is itself an lvalue. The basic rule to remember is – if it has a name, it’s an lvalue. There are very few contexts where an lvalue may automatically be moved from (such as … Read more
As documented in tcp::socket reference: Following the move, the moved-from object is in the same state as if constructed using the basic_stream_socket(io_service&) constructor. The above means that you can move the original socket object from server to session as many times as you need.
You know the classes A and B, so you know if they are movable or not and if this design is ultimately necessary. For something like std::string, it’s a waste of time changing the existing code unless you know you have a performance problem here. If you’re dealing with auto_ptr, then it’s time to rip … 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