Boost logo

Boost :

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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at