I haven't been closely monitoring this thread, though I did note its existence.
Fwiw, I was never thrilled with my C++03 emulation of unique_ptr. I don't recall exactly what doesn't work. But I think I'm correct when I say that it does not succeed in completely emulating a C++11 unique_ptr. There may be clues as to what doesn't work here: http://home.roadrunner.com/~hinnant/unique_ptr.zip
Howard
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. Howard's implementation did bring something interesting up I noticed about the standard on array unique_ptr: There is no move constructor/assignment of the form: // constructor form here, similar issue with move assignment unique_ptr<T[], D>(move(unique_ptr<T[], U>)) Assuming I'm interpreting the standard correctly, this technically is a compiler error even if U is implicitly convertible to D and D is not a reference (e.g. U == D&). This is not the case for single element unique_ptr. Single element unique ptr will copy-construct D if U is implicitly convertible and a reference. I don't know if this was intentionally done by the standards committee, or if it was a minor oversight. Howard's implementation does not allow this, GCC 4.8.1 allows this. Thoughts/comments on how we should handle this in boost? My current implementation follows GCC's implementation, but it is very easy to change.