|
Boost : |
Subject: Re: [boost] unique_ptr for C++03
From: Adam Romanek (romanek.adam_at_[hidden])
Date: 2013-08-08 05:56:50
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk