Convert a shared_ptr to regular a pointer

Question

We have a function that returns a new allocated object as a output argument (ref to pointer).

MyFunc(MyObject*& obj)
{
    obj = new MyObject();
}

Which is called like so:

Object* obj;
MyFunc(obj);

Internally the function does quite a bit and uses shared_ptr for memory management. When it is done, the object we would like to return is referenced by a shared_ptr. I am struggling on how to return our new allocated object as a regular pointer.

We would like to continue to use shared_ptr internally to reduce risks, but it does not seem to make sense to return a shared_ptr as the caller takes complete ownership over the returned value (the called function or object no longer needs or keeps a reference to the returned data) and we want them to have flexibility.

Does anyone have any suggestions for allowing us to use shared_ptr internally but have a regular pointer interface? Thanks

Answer 1

It depends on who "owns" the pointer, once it has been exposed to the 'outside world.' Ownership essentially boils down to: "who is responsible for freeing this memory, later?"

It can be answered with a simple question: when MyFunc is called, is the caller responsible for deleting the pointer when it's done?

1. If so, then MyFunc needs to 'release' the ownership, otherwise the shared_ptr will automatically delete the pointer, when it goes out of scope. This actually can't be done, using shared_ptr. You need to use a unique_ptr instead, and call unique_ptr::release().
2. If not - if MyFunc will simply use the resulting pointer and forget about it without delete-ing it - then you can simply return the 'raw' pointer using shared_ptr::get(). You must be careful, because this implies that the shared_ptr still exists elsewhere in your code.

Answer 2

If for some reason you cannot/want not use std::unique_ptr or std::auto_ptr (for example if you need to have multiple owners internally during creation for some reason or your underlying methods require std::shared_ptr to be passed around), you can still make it work with std::shared_ptr by using custom deleter, as described here: https://stackoverflow.com/a/5995770/1274747

In the principle, after you're done before the return, you switch the deleter to not actually delete the instance (make the deleter "null") and then return by shared_ptr get(). Even after all shared_ptr objects are destroyed, the memory will not be deleted (as the nulled deleter will skip the deletion).

There is also a link in the comments not so well visible, which might be of your interest: http://paste.ubuntu.com/23866812/ (not sure though if it would really work without the shared ownership of the switch in all cases, would need to test)

---

EDIT

As expected, with the linked simple disarmable deleter from the pastebin you need to be careful, because the deleter is actually copied for storing in std::shared_ptr.

But you can still make it work by using std::ref:

MyFunc(MyObject*& obj)
{
    DisarmableDelete<MyObject> deleter;
    std::shared_ptr<MyObject> ptr(new MyObject(), std::ref(deleter));
    // do what is necessary to setup the object - protected by deleter
    // ...
    // disarm before return
    deleter._armed = false;
    obj = ptr.get();
    // deleter disarmed - object not freed
}

And just for completeness (and to avoid a potential future broken link), here is the implementation of DisarmableDelete from http://paste.ubuntu.com/23866812/.

template <typename T, typename Deleter = typename std::default_delete<T> >                                                                                                                              
    struct DisarmableDelete : private Deleter {                                                                                                                                                         
        void operator()(T* ptr) { if(_armed) Deleter::operator()(ptr); }                                                                                                                                
        bool _armed = true;                                                                                                                                                                             
    };        

Answer 3

I can see four alternatives, as highlighted below. They are all horrible, and short of switching your ownership to std::unique_ptr<T> and returning via obj = ptr.release(); I can only offer a hack where the argument is assigned to the pointer upon destruction, but you still need to catch the exception and test whether the pointer was assigned.

#include <iostream>
#include <memory>
#include <exception>

struct foo {
  void bar() const { std::cout << this << " foo::bar()\n"; }
  ~foo() { std::cout << this << " deleted\n"; }
};

void f1(foo*& obj) {
  obj = new foo;
  // do stuff... if an exception is thrown before we return we are
  // left with a memory leak
}

void f2(foo*& obj) {
  auto holder = std::make_shared<foo>();
  // do stuff.. if an exception is thrown the pointer will be
  // correclty deleted.

  obj = holder.get(); // awesome, I have a raw pointer!
} // oops, the destructor gets called because holder went out of
  // scope... my pointer points to a deleted object.

void f3(foo*& obj) {
  auto holder = std::make_unique<foo>();
  // do stuff.. if an exception is thrown the pointer will be
  // correclty deleted.

  obj = holder.release(); // awesome, I have a raw pointer!
} // no problem whem holder goes out of scope because it does not own the pointer

void f4(foo*& obj) {
  // a super-weird hack that assigns obj upon deletion
  std::shared_ptr<foo> holder(new foo, [&obj](foo*& p){  obj = p; });
  throw std::exception();
} // no problem whem holder goes out of scope because it does not own
  // the pointer... but if an execption is throw we need to delete obj

int main() {

  foo* p1;
  f1(p1);
  p1->bar();

  foo* p2;
  f2(p2);
  // p2->bar(); // error

  foo* p3;
  f3(p3);
  p3->bar();

  foo* p4;
  try {
    f4(p4);
  } catch(...) {
    std::cout << "caught an exception... test whether p4 was assigned  it\n";
  }
  p4->bar(); // I still need to delete this thing
}

Answer 4

The point of shared_ptr is to express shared ownership.

Anything that does not share in the ownership of an object -- that doesn't have the right to make an object lifetime last longer, and the object lifetime is the union of the shared owners request for object lifetime -- should not use a shared_ptr.

Here, you have a shared_ptr and you are going to return it. At that point, you are violating the assumptions of shared_ptr; anyone who kept a shared_ptr copy expects that its content can last as long as it requests.

Meanwhile, the calling code thinks it owns the MyObject* raw pointer you passed it.

This is an example of misuse of shared_ptr.

Saying "we have memory management issues, use shared_ptr" doesn't fix memory management issues. Proper use of shared_ptr requires care and design, and the design must be that when the end of the lifetime of the object in question is shared by 2 or more pieces of data and/or code.

The internal code, if it does not own the pointer, should use either something like an observer_ptr<T> or a raw T* (the first to make it clear it doesn't own the object).

Ownership should be explicit, and in a unique_ptr. It can then call .release() to pass ownership to a raw pointer if required; in practice, I would change your signature to take a unique_ptr&, or have it return a unique_ptr.

The caller would then call .release() when they want to use some other object lifetime management system, or that object lifetime management system should consume unique_ptrs (thus being extremely clear about taking ownership of things).

---

Use a non-hack solution.

Such as a std::shared_ptr<std::unique_ptr<T>>. In this case, you have shared ownership of a unique ownership.

The unique_ptr can have its ownership taken from it (via .release()). When it does so, all of the shared_ptrs that still exist will have their unique_ptr also be cleared.

This places the shared unique ownership front and center, instead of hacking a non-deleter into a shared_ptr and having dangling shared_ptrs that think they have ownership over data but do not.

Answer 5

The best approach is to use internally unique_ptr and call its .release() method before returning the raw pointer.

If you are stuck to use shared_ptr internally, an option is to create it specifying a custom, "noop" deleter, that just does nothing when shared_ptr is destroyed (instead of calling delete on the owned pointer). The get the raw pointer from shared_ptr as usual (.get() method). An example of such a deleter can be found in the Boost library (null_deleter).
But please note that doing this effectively "disable" the usefulness of having a shared_ptr at all...

Answer 6

If your managing the lifespan of the allocated object internally with std::shared_ptr, and are returning a raw pointer for access and don't want this pointer to affect the ref count, you can return the raw pointer by calling shared_ptr.get().

It can be problematic to return smart pointers if your using a tool like Swig to generate wrappers for other languages.