Re: [boost] boost::thread and move semantics (was Re: [RFC][threads] Header/namespace policy draft)

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
>>> 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.