Re: [boost] [move][unique_ptr] c++14 unique_ptr comes to town

Subject: Re: [boost] [move][unique_ptr] c++14 unique_ptr comes to town
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-08-23 17:47:34

Hi Ion,

Ion Gaztañaga wrote:
> Hi to all,
>
> We've discussed about a boostified version of std::unique_ptr several 
> times in later years. I decided we could not continue with this hole 
> in the Boost toolset and implemented in Boost.Move a unique_ptr that 
> follows the C++14 interface.
That's great news. Boost should have its own implementation of 
unique_ptr. Thanks for your hard work!

<snip>
> -> Implemented in two headers: <boost/move/unique_ptr.hpp> and 
> <boost/move/make unique.hpp>.
>
> -> <boost/move/unique_ptr.hpp>: Boost.Move is the only heavyweight 
> dependency. Not even that, as unique_ptr.hpp only uses 
> boost/move/utility_core.hpp, that does not depend on any external 
> library excepct BoostConfig and StaticAssert. No TypeTraits, MPL and 
> others. Only Boost.Config, BOOST_STATIC_ASSERT and BOOST_ASSERT are 
> used in the implementation. No standard library headers used (no 
> pointer_traits, memory or other utilities).
>
> -> <boost/move/make unique.hpp>: Boost.PP is used in compilers without 
> variadic templates. This is the main reason to have a separate 
> make_unique.hpp header and avoid pulling Boost.PP for c++03 users that 
> only want to have C++11 unique_ptr.
>
AFAIS this is in line with the Boost.SmartPtr library, e.g. shared_ptr 
and make_shared aren't included together, correct me if I'm wrong. The 
difference is that make_shared doesn't emulate variadic templates using 
Boost.PP. And there is an implementation of boost::make_unique returning 
std::unique_ptr<> so I'm guessing that there may be a problem with 
backward compatibility.

<snip>
> I hope you find this addition to Boost.Move useful. If you think the 
> implementation is good enough to be the official boost::unique_ptr 
> implementation living in Boost.SmartPtr, porting should be easy, 
> except for the documentation part. That would require either combining 
> somehow handwritten and Quickbook produced documentation or writing 
> new docs for unique_ptr. 

IMHO we should go towards the official implementation. However AFAIU 
unique_ptr might not reside in the Boost.SmartPtr, it might stay in 
Boost.Move module or be moved to some separate one (UniquePtr). It's 
because it'd introduce additional dependencies to SmartPtr (Move and 
PP). It should be transparent for the user. The only problem I see is 
the boost/make_unique.hpp (in SmartPtr) including the implementation 
working differently than yours.

Regards,
Adam