The reason this fails is because when you specify foo<Movable>, the function you’re binding to is: void foo(Movable&&) // *must* be an rvalue { } However, the value passed by std::bind will not be an rvalue, but an lvalue (stored as a member somewhere in the resulting bind functor). That, is the generated functor is … Read more
There are a few occasions when it is appropriate, but they are relatively rare. The case comes up in one example when you want to allow the client to move from a data member. For example: template <class Iter> class move_iterator { private: Iter i_; public: … value_type&& operator*() const {return std::move(*i_);} … };
You have to understand the forwarding problem. You can read the entire problem in detail, but I’ll summarize. Basically, given the expression E(a, b, … , c), we want the expression f(a, b, … , c) to be equivalent. In C++03, this is impossible. There are many attempts, but they all fail in some regard. … Read more
with your design: void doWork(Widget && param) { Widget store1 = param; // automatically move param Widget store2 = param; // boom Widget store_last = param; // boom } with current design: void doWork(Widget && param) { Widget store1 = param; // ok, copy Widget store2 = param; // ok, copy Widget store_last = std::move(param); … Read more
You can restrict T to not be an lvalue reference, and thus prevent lvalues from binding to it: #include <type_traits> struct OwnershipReceiver { template <typename T, class = typename std::enable_if < !std::is_lvalue_reference<T>::value >::type > void receive_ownership(T&& t) { // taking file descriptor of t, and clear t } }; It might also be a good … Read more
This is one of the most common “rules of thumb” used to explain what is the difference between lvalues and rvalues. The situation in C++ is much more complex than that so this can’t be nothing but a rule of thumb. I’ll try to resume a couple of concepts and try to make it clear … Read more
No. Consider: using X = std::shared_ptr<int>; void g(X); void f() { X b = std::make_shared<int>(); int &i = *b; g(b); // last use of ‘b’ i = 5; } In general, the compiler cannot assume that altering the semantics of copies, moves and destructors of X will be a legitimate change without performing analysis on … Read more
The two are very different and complementary tools. std::move deduces the argument and unconditionally creates an rvalue expression. This makes sense to apply to an actual object or variable. std::forward takes a mandatory template argument (you must specify this!) and magically creates an lvalue or an rvalue expression depending on what the type was (by … Read more
It’s my fault. (half-kidding, half-not). When I first showed example implementations of move assignment operators, I just used swap. Then some smart guy (I can’t remember who) pointed out to me that the side effects of destructing the lhs prior to the assignment might be important (such as the unlock() in your example). So I … Read more
Given this example, X foo () { X x; return x; } the following behavior is guaranteed: • If X has an accessible copy or move constructor, the compiler may choose to elide the copy. This is the so-called (named) return value optimization ((N)RVO), which was specified even before C++11 and is supported by most … Read more