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 14:49:42

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