Re: [boost] C++03 unique_ptr emulation

Subject: Re: [boost] C++03 unique_ptr emulation
From: Howard Hinnant (hinnant_at_[hidden])
Date: 2009-01-02 19:00:40

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