Re: [Threads-devel] thread_move_t question

From: Anthony Williams (anthony_at_[hidden])
Date: 2008-04-11 16:14:06

Quoting Frank Mori Hess <frank.hess_at_[hidden]>:

> I'm updating the mutex types in libpoet to conform to the new boost.threads
> api and I've got a question about the move emulation in boost.thread.  Since
> the lock types are convertible to thread_move_t<>, and the assignment
> operators only accept thread_move_t<> types (no "normal" assignment), it
> seems like I could get the same behavior without using thread_move_t<> or its
> equivalent at all.  That is, I could just define an assignment operator like
>
> lock_type& operator=(lock_type&);
>
> And define the assignment operator to pilfer the internal state of the right
> hand side.  Am I missing something?  I don't have much (any) experience with
> move emulation or right hand references.

The lock types have a (private, unimplemented) assignment operator  
with the signature above, as well as the move assignment operator in  
order to prevent accidental moving: moving has to be explicit if  
you've got an lvalue rhs. A non-const lvalue will bind to the "normal"  
assignment operator during overload resolution, and fail as it's  
private. An rvalue cannot bind to a non-const reference (except on  
MSVC, unfortunately), so the only option is the conversion to  
thread_move_t<> and the thread_move_t<> assignment operator.

boost::unique_lock<boost::mutex> a(some_mutex);

boost::unique_lock<boost::mutex> b;

b=a; // won't compile ***
b=a.move(); // fine

b=boost::unique_lock<boost::mutex>(some_other_mutex); // fine

If you just provide a simple assignment operator then the line marked  
*** will compile, which is undesirable.

Anthony
-- 
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL