tags:

views:

345

answers:

4

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.
}
+2  A: 

How about unique_ptr from the interprocess library?

fbrereto
Can that be returned from a function safely? I couldn't find anything about that (but maybe I'm just blind). Also, is it the "right" thing to use, given that it's in the interprocess library instead of the smart pointers library?
Clark Gaebel
@wowus: No. That relies on move semantics which are new in C++0x. That can't be simply emulated by boost -- that feature has to exist in the compiler itself.
Billy ONeal
Just looked, it needs r-value references. Therefore, not what I'm looking for.
Clark Gaebel
Interprocess unique_ptr has its own move emulation for C++03, that is the same as Boost.Move if I'm not wrong.
Vicente Botet Escriba
+5  A: 

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.
jalf
+1 for `auto_ptr` - since `unique_ptr` will not compile in the [places that auto_ptr causes bugs](http://stackoverflow.com/questions/111478/why-is-it-wrong-to-use-stdauto-ptr-with-stl-containers), this is exactly what OP is looking for.
BlueRaja - Danny Pflughoeft
Howard Hinnant's unique_ptr for c++03 works pretty well considering r-value refs don't exist.
caspin
This is not completely true, as Howard Hinnant's demonstrated using the its move semantics emulation that has been reviewed already on Boost. I hope that someone will take its implementation and include it on Boost soon.
Vicente Botet Escriba
+3  A: 

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));
}
Michael Burr
I have used this in production code, it works pretty well. The only issue we has was calling `boost::make_shared`, for a `class` with a `unique_ptr` parameter.
caspin
+3  A: 

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.

caspin