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_smar...), 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