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