unique_ptr boost equivalent?

C++BoostC++11Unique Ptr

C++ Problem Overview


Is there some equivalent class for C++1x's std::unique_ptr in the boost libraries? The behavior I'm looking for is being able to have an exception-safe factory function, like so...

std::unique_ptr<Base> create_base()
{
    return std::unique_ptr<Base>(new Derived);
}

void some_other_function()
{
    std::unique_ptr<Base> b = create_base();

    // Do some stuff with b that may or may not throw an exception...

    // Now b is destructed automagically.
}

EDIT: Right now, I'm using this hack, which seems like the best I can get at this point...

Base* create_base()
{
    return new Derived;
}

void some_other_function()
{
    boost::scoped_ptr<Base> b = create_base();

    // Do some stuff with b that may or may not throw an exception...

    // Now b is deleted automagically.
}

C++ Solutions


Solution 1 - C++

It's not possible to create something like unique_ptr without C++0x (where it's part of the standard library, and so Boost doesn't need to provide it).

Specifically without rvalue references, which are a feature in C++0x, a robust implementation of unique_ptr is impossible, with or without Boost.

In C++03, there are a few possible alternatives, although each have their flaws.

  • boost::shared_ptr is probably the simplest replacement in terms of capabilites. You can safely use it anywhere you'd otherwise use a unique_ptr and it'd work. It just wouldn't be as efficient, because of the added reference counting. But if you're looking for a simple drop-in replacement that's able to handle everything unique_ptr can do, this is probably your best bet. (Of course, a shared_ptr can do a lot more as well, but it can also simply be used as a drop-in replacement for unique_ptr.)
  • boost::scoped_ptr is similar to unique_ptr but does not allow transfer of ownership. It works great as long as the smart pointer is meant to retain exclusive ownership throughout its lifetime.
  • std::auto_ptr works very similar to unique_ptr, but has a few limitations, mainly that it can not be stored in standard library containers. If you're simply looking for a pointer that allows transfer of ownership, but which is not meant to be stored in containers or copied around, this is probably a good bet.

Solution 2 - C++

Starting from Boost 1.57 there's an official unique_ptr implementation in Boost.Move library.

From the documentation:

> (...) a drop-in replacement for std::unique_ptr, usable also from C++03 > compilers.

The code is available in <boost/move/unique_ptr.hpp> header file and lives in boost::movelib namespace. Moreover, Boost.Move library provides make_unique() factory function in <boost/move/make_unique.hpp>, also in boost::movelib namespace.

Hence the example from the question could be implemented this way:

#include <boost/move/unique_ptr.hpp>

using boost::movelib::unique_ptr;

unique_ptr<Base> create_base()
{
    return unique_ptr<Base>(new Derived);
}

See a live example on Wandbox. Note that the code compiles fine with gcc 4.6.4 in C++98 mode (!).

What's interesting in boost::movelib::unique_ptr when applied to your case with base/derived classes, the implementation provides a compile-time check for the declaration of a virtual destructor in the base class. If you happen to omit it the code won't compile (click the "Run (...)" button to see the compiler error message).

One minor issue is that includes come from boost/move directory but the code lives in boost::movelib namespace (subtle difference but can be annoying).

See also a thread on boost mailing list for more details.

Thanks to Ion Gaztañaga for this absolutely unique and useful piece of code.

Solution 3 - C++

You might want to try Howard Hinnant's 'proof of concept' unique_ptr<> implementation for C++03 (disclaimer - I haven't):

One of his examples is returning a unique_ptr<int>:

unique_ptr<int> factory(int i)
{
    return unique_ptr<int>(new int(i));
}

Solution 4 - C++

How about unique_ptr from the interprocess library?

Solution 5 - C++

I've used Howard Hinnant's unique_ptr. If you are not really good at reading crazy metaprogramming errors from you compiler you might want to steer clear. It however does act just like a unique_ptr in 90% of the cases.

Otherwise I'd suggest passing paramters as boost::scoped_ptr& and swap internally to steal ownership. To get unique_ptr style return values use an auto_ptr. Capture the auto_ptr return value in a shared_ptr or scoped_ptr to avoid using the auto_ptr directly.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionClark GaebelView Question on Stackoverflow
Solution 1 - C++jalfView Answer on Stackoverflow
Solution 2 - C++Adam RomanekView Answer on Stackoverflow
Solution 3 - C++Michael BurrView Answer on Stackoverflow
Solution 4 - C++fbreretoView Answer on Stackoverflow
Solution 5 - C++deft_codeView Answer on Stackoverflow