Anthony Williams wrote:
Andrey Semashev <andysem <at> mail.ru> writes:
Anthony Williams wrote:
Anthony Williams <anthony_w.geo <at> yahoo.com> writes:
Currently, the boost::move in question is an implementation detail of thread. It is an oversight that it is in the boost namespace and not the detail namespace. I have now fixed this: I have renamed it to boost::detail::thread_move (and boost::detail::thread_move_t Hmm... I guess that means users are not allowed to move Boost.Thread components. That's a shame, because I was using this feature in my development.
That's not the intention. This is (largely) an implementation detail to make up for the lack of rvalue references.
boost::thread make_thread() { return boost::thread(some_func); }
boost::thread x=make_thread();
"just works" --- I added an explicit test for it this morning.
Moving from an lvalue used to be done with boost::move(x), and is now boost::detail::thread_move(x) or x.move() (if x is a boost::thread).
Maybe moving to boost::threads namespace or just renaming them would be a better solution?
We could just have boost::thread_move become a documented public interface, and have the type remain in boost::detail (since it *is* an implementation detail).
Actually, I used it to move locks, which don't have a move member. I worked around this issue by using defer_lock_t and swap but it looks clumsy and I would surely prefer using move in such cases. As for possible solution, I feel fine if thread_move is public and thread_move_t is private. I guess, we'll have to wait until the full-featured move library comes up in order to make use of the type.