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
> 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).
> 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
> Interprocess containers already support emplace and move semantics
> so we can have containers of unique_ptrs or boost::threads.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk