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
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!
> -> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk