Re: [boost] unique_ptr for C++03

I would be very interested in seeing a C++03 based unique_ptr as part of Boost.SmartPtr

Back in March there was some discussion about moving the unique_ptr implementation of Boost.Interprocess to Boost.SmartPtr. What happened to that proposal?

I actually didn't know Boost.Interprocess existed before. The interface looks very similar to standard c++11 unique_ptr, and if it matches the standard implementation as closely as possible, it would probably be a better fit because the implementation is likely to be less buggy.

Maybe you could use the safe-bool idiom.

Ah, thanks. Updated to use the safe-bool idiom.

PS: I recommend that you use your real name in the copyright line rather than your handle. I do not think that the latter is legally valid.

Fair enough. Updated copywrite info. Does anyone know of nullptr emulated type already in Boost (similar to http://stackoverflow.com/a/8747659/558546)? I think this would be the best way to allow this: my_uptr = nullptr; // effectively my_uptr.reset(); if(my_uptr == nullptr) // technically valid, though not sure if there's significant gains from verbose writing vs. if(my_uptr) I did some testing trying to store my unique_ptr implementation into a std::vector, and things did not go well using a C++03 compiler (standard library templates obviously aren't move aware in C++03). I'm not sure there's any way to fix this for C++03 without re-implementing the standard library containers, which really isn't practical. I think this implementation does work properly with array types. // on p1 destruction, delete[] is called, as expected boost::unique_ptr p1(new int[2]); // compilation error, as expected boost::unique_ptr<int> p2 = boost::move(p1); // compiles, but so does std::unique_ptr // both will produce undefined runtime behavior on destruction of held value // dunno if this is GCC-4.8.1 specific, or if technically allowed by the standard and is user error. boost::unique_ptr<int> p3(new int[2]);