From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-12-04 18:08:52
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
>> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk