Boost logo

Threads-Devel :

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 Williams            | Just Software Solutions Ltd
Custom Software Development |
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

Threads-Devel list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at