On Jan 2, 2009, at 6:45 PM, Ion Gaztañaga wrote:
I've seen that move emulation is done using a conversion operator (I think Boost.Thread uses the same technique), is that mechanism the best way to achieve this?
It is my current best effort. :-\ It does not have the move-from- const bug that my previous effort had. And it does not require clients to be aware of the "rv" or "moved-from" type (which is a characteristic I really like). In this emulation I've made that type private to emphasize the encapsulation of it from clients wanting to move unique_ptr's.
Interprocess' own move-semantics are based on Dave Abramams good old move library so we already have different solutions for the same problem. I'm aware also of Adobe's Move library but that library requires Regular types (copy constructible).
<nod>
It would be great if we could adopt your unique_ptr version and agree a general move emulation protocol so that we can make Boost libraries interoperable.
Agreed. The thing I like about my current effort is that clients see either lvalue or rvalue unique_ptr's (or whatever class you're trying to move-enable) and nothing else. No moved-from wrappers. Downsides include the fact that move(unique_ptr) is a friend of unique_ptr - a tight coupling that I would rather not have there. In C++0X, move is a completely generic std-function, a characteristic not achieved by this emulation.
Interprocess containers already support emplace and move semantics so we can have containers of unique_ptrs or boost::threads.
Great! :-) -Howard