[…] will the compiler be able to optimize away the extra initializations? In almost all cases: yes. Should I always write my move constructors by calling the move assignment operator? Yes, just implement it via move assignment operator, except in the cases where you measured that it leads to suboptimal performance. Today’s optimizer do an … Read more
You declare a function to return by r-value reference – this should almost never be done (if you return the local object by reference, you will end up with a dangling reference). Instead declare the function to return by value. This way the caller’s value will be move constructed by the r-value returned by the … Read more
If you declare a copy constructor (even if you define it as deleted in the declaration), no move constructor will be declared implicitly. Cf. C++11 12.8/9: If the definition of a class X does not explicitly declare a move constructor, one will be implicitly declared as defaulted if and only if — X does not … Read more
Yes there is a very important difference: std::move documents what you want to do. In addition the cast is prone to writing errors like a forgotten & or wrong type X. As it can be seen, std::move is even less to type.
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
I believe that there are several places in D (such as returning structs) that D manages to make them moves whereas C++ would make them a copy. IIRC, the compiler will do a move rather than a copy in any case where it can determine that a copy isn’t needed, so struct copying is going … Read more
For the start, std::mutex can not be copied or moved, therefore you are forced to use some kind of indirection. Since you want to store mutex in a vector, and not copy it, I would use std::unique_ptr. vector<unique_ptr<T>> does not allow certain vector operations (such as for_each) I am not sure I understand that sentence. … Read more
Summary: For C++11 I would include: move-ctor (noexcept) move-assign (noexcept) total ordering (operator<() for natural total order and std::less<> if a natural total order does not exist). hash<> And would remove: swap() (non-throwing) – replaced by move operations. Commentary Alex revisits the concept of a regular type in Elements of Programming. In fact, much of … Read more
There’s no right answer, but returning by value is safer. I have read several questions on SO relating to returning rvalue references, and have come to the conclusion that this is bad practice. Returning a reference to a parameter foists a contract upon the caller that either The parameter cannot be a temporary (which is … Read more
No, AnyTypeMovable&& r = move(v); here is not useful at all. Consider the following code: #include <iostream> #include <vector> class MyMovableType { int i; public: MyMovableType(int val): i(val){} MyMovableType(MyMovableType&& r) { this->i = r.i; r.i = -1; } MyMovableType(const MyMovableType& r){ this->i = r.i; } int getVal(){ return i; } }; int main() { std::vector<MyMovableType> … Read more