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.