best practice when returning smart pointers

What is the best practice when returning a smart pointer, for example a boost::shared_ptr? Should I by standard return the smart pointer, or the underlying raw pointer? I come from C# so I tend to always return smart pointers, because it feels right. Like this (skipping const-correctness for shorter code):

class X
{
public:
    boost::shared_ptr<Y> getInternal() {return m_internal;}

private:
    boost::shared_ptr<Y> m_internal;
}

However I've seen some experienced coders returning the raw pointer, and putting the raw pointers in vectors. What is the right way to do it?

---

There is no "right" way. It really depends on the context.

You can internally handle memory with a smart pointer and externally give references or raw pointers. After all, the user of your interface doesn't need to know how you manage memory internally. In a synchronous context this is safe and efficient. In an asynchronous context, there are many pitfalls.

If you're unsure about what to do you can safely return smart pointers to your caller. The object will be deallocated when the references count reaches zero. Just make sure that you don't have a class that keeps smart pointers of objects for ever thus preventing the deallocation when needed.

As a last note, in C++ don't overuse dynamically allocated objects. There are many cases where you don't need a pointer and can work on references and const references. That's safer and reduces the pressure on the memory allocator.

---

It depends on what the meaning of the pointer is.

When returning a shared_pointer, you are syntactically saying "You will share ownership of this object", such that, if the the original container object dies before you release your pointer, that object will still exist.

Returning a raw pointer says: "You know about this object, but don't own it". It's a way of passing control, but not keeping the lifetime tied to the original owner.

(in some older c-programs, it means "It's now your problem to delete me", but I'd heavily recommend avoiding this one)

Typically, defaulting to shared saves me a lot of hassle, but it depends on your design.

---

I follow the following guidelines for passing pointers arguments to functions and returning pointers:

boost::shared_ptr

API and client are sharing ownership of this object. However you have to be careful to avoid circular references with shared_ptr , if the objects represent some kind of graph. I try to limit my use of shared_ptr for this reason.

boost::weak_ptr / raw pointer

API owns this object, you are allowed share it while it is valid. If there is a chance the client will live longer than the api I use a weak_ptr.

std::auto_ptr

API is creating an object but the client owns the object. This ensures that the returning code is exception safe, and clearly states that ownership is being transferred.

boost::scoped_ptr

For pointers to objects stored on the stack or as class member variables. I try to use scoped_ptr first.

Like all guidelines there will be times when the rules conflict or have to be bent, then I try to use intelligence.

链接地址: http://www.djcxy.com/p/79938.html

上一篇: 自动指针问题

下一篇: 返回智能指针时的最佳做法