On 08/08/2013 11:38 AM, Andrew Ho wrote:
Hi, I took a look at your implementation and incorporated parts of it into my implementation.
I wrote some compiler tests to see how well an implementation of unique_ptr stood up to the standard's requirements.
The main issues I found with Howard's implementations are (from a compilation success standpoint, I haven't tried compilation failure test cases):
1. Incompatibility with Boost.Move, and possibly certain Boost type traits. 2. It seems like a few areas rely on reference collapsing, which isn't available in C++03 (well, that's what GCC 4.8.1 is telling me. Dunno if his use is non-standard compliant). 3. There are some places the compiler complains about ambiguous use of forward. Seems to primarily be a problem if D is a reference.
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). 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]). 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. [1] - https://svn.boost.org/trac/boost/ticket/7598 WBR, Adam Romanek