Hi,
I am the one who started the "unique_ptr in C++03" topic on this list back in March. Unfortunately, I didn't have the time to work on its conclusions (i.e. move / port Boost.Interprocess' unique_ptr to Boost.SmartPtr).
AFAIK, the implementation of Boost.Interprocess' unique_ptr is based on Howard Hinnant's code (see the header of boost/interprocess/smart_ptr/unique_ptr.hpp).
Hi, I tried running Boost.Interprocess's unique_ptr through my compilation test suite. The implementation seems to make use of Boost.Move and places custom typetraits not in the boost namespace, so it should be compatible with both libraries. Notable failures: 1. No default_delete (easy to fix) 2. unique_ptr must specify deleter type (easy to fix) 3. Similar to Howard's implementation, there are issues with having D as a reference (forming reference to reference, forward implementations don't handle this case correctly) 4. I noticed in the code specialization for array unique_ptr has been commented out (boost/interprocess/smart_ptr/unique_ptr.hpp). Why? I don't know if it's in an external header file, but otherwise handling of array types won't work per standard.
I can only say that I've been using Boost.Interprocess' unique_ptr in a production code for a few months without any problems (not including [1]). [1] - https://svn.boost.org/trac/boost/ticket/7598
That's good to know. [1] has been fixed. The biggest bugs I have found with Howard's and Interprocess's unique_ptr deal with having D as a reference, which seems to be a rather obscure use case, which looks like is a rather obscure use case, but should still be handled properly if we want to emulate std::unique_ptr as closely as possible. Actually, [1] brought out a bug in my code which I had originally tried to avoid because boost::forward doesn't handle references correctly (there are bits in my implementation which explicitly avoid the use of boost::forward because of this). Looks like I'll have to look into properly implementing this to properly support D == A&.
As for C++03 emulated unique_ptr and std containers - I don't think these could ever work together properly. Fortunately, we have containers from Boost.Container which are move-aware and should work with unique_ptr emulations without problems.
WBR, Adam Romanek
I expected as much. C++03 std containers require copy-constructible objects and unique_ptr requires non-copyable.