What is the sense of a shared_ptr to a container?

What actu开发者_StackOverflow中文版ally is the point of declaring a boost::shared_ptr to a container like std::vector or std::list?

Here is an example utilizing BOOST_AUTO.

void someFunction()
{
  ...
  BOOST_AUTO(sharedPtrToContainer, boost::make_shared<std::vector<T>>());
  ...
}

Is there any sense if you only need the container locally? What is the benefit? What would be the uses of a shared_ptr to a container?

What actually is the point of declaring a boost::shared_ptr to a container like std::vector or std::list?

Exactly the same point as using a shared pointer to any object type; it allows you to share ownership of the object with other scopes. It doesn't make any difference that the object happens to be a container.

Is there any sense if you only need the container locally?

No; if you only need it locally, then it should be an ordinary automatic object.

What is the benefit? What would be the uses of a shared_ptr to a container?

If you need to extend its lifetime beyond the current scope, then you'll need to create and destroy it dynamically, and then its lifetime should be managed by smart pointers.

If you simply declare a container full of pointers to objects allocated on the heap, it's very easy if you're not careful, to allow the container to go out of scope, and at that point, you have a memory leak. This is because the container only takes ownership of the type that is allocated in the container. For instance, for a std::vector<T*>, the vector will only maintain ownership of allocating memory to contain an series of pointers ... it will not maintain ownership for the objects those pointers are pointing to. This is simply because it can't ... how would the container know that it was pointing to a heap object and not something else? And if it were pointing to a heap object, how would it know that it were the only reference to that heap object, and it could delete it when necessary and not create a bunch of dangling pointers? The reality is because STL containers don't carry that sort of global state information, they can't possibly know the answers to those questions, and therefore the only memory managed by an STL container is the memory it allocates for its own objects that it controls. Thus when a container that is storing pointers goes out of scope, the memory used to allocate the pointers will be properly destroyed, but the container itself will not call delete on each pointer to deallocate the object that each pointer was pointing to on the heap. Using std::shared_ptr<T> as the type for an STL container allows the container to pass out-of-scope and remove the memory that was allocated for each shared_ptr allocated within the array. Because of the reference-counting object-state information stored within a shared_ptr though, once the last reference to an object has been deleted, it will itself properly destroy the the object on the heap it is managing. Therefore if you had an STL container that went out-of-scope, any shared_ptrs in that container that were the last reference to the object they were pointing to would properly destroy the object on the heap, and you wouldn't end up with a series of memory leaks from pointers being lost to heap objects.

If you only need it locally, then use an automatic instance:

std::vector<T> inst;

If you need to return and T is heavy (or vector is ridiculously large), then use either the shared_ptr or vector of pointers (T is heavy and it's small), else return by value, for example vector<int>, depending on size, may as well return by value (I guess depends heavily on what the caller is going to do with it)...