Re: [boost] unique_ptr for C++03

Subject: Re: [boost] unique_ptr for C++03
From: Andrew Ho (helloworld922_at_[hidden])
Date: 2013-08-08 05:38:12

> 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.