|
Boost : |
Subject: Re: [boost] C++03 unique_ptr emulation
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2009-01-02 18:45:55
Howard Hinnant wrote:
> I've put up a new version of an C++03 emulated unique_ptr here:
>
> http://home.roadrunner.com/~hinnant/unique_ptr03.html
>
> This is a "boost-ized" emulation (uses boost tools and is in boost
> namespace), though I have reason to believe it may not work well on
> VC++05 unless the /Za option is used (I've tested only on gcc 4.0).
Great!
> I'm aware of Ion's interprocess version
> (http://www.boost.org/doc/libs/1_35_0/doc/html/interprocess/interprocess_smart_ptr.html#interprocess.interprocess_smart_ptr.unique_ptr),
> and thank Ion for his support over the years. This new version is not
> meant to replace Ion's version. It is simply my current best shot at
> emulating the unique_ptr behavior as specified in the C++0X CD1 draft.
> Booster's are welcome to take parts of this implementation and use them
> in places like interprocess/unique_ptr. Or to just use this unique_ptr
> directly. It consists of only one header: unique_ptr.hpp, and requires
> only boost headers, not boost cpp files.
I would be really glad if I could just drop Interprocess' own version,
since your version also covers non-raw pointers. 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?
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. Interprocess containers already support emplace and move
semantics so we can have containers of unique_ptrs or boost::threads.
Regards,
Ion
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk