Shared_ptr 对于容器来说有什么意义?
向 std::vector
或 std::list
等容器声明 boost::shared_ptr
到底有什么意义?
下面是一个利用 BOOST_AUTO
的示例。
void someFunction()
{
...
BOOST_AUTO(sharedPtrToContainer, boost::make_shared<std::vector<T>>());
...
}
如果您只需要本地容器有什么意义吗?有什么好处?容器的 shared_ptr
有什么用途?
What actually 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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
与使用指向任何对象类型的共享指针完全相同;它允许您与其他范围共享对象的所有权。对象恰好是一个容器并没有什么区别。
不;如果您只在本地需要它,那么它应该是一个普通的自动对象。
如果您需要将其生命周期延长到当前范围之外,那么您需要动态创建和销毁它,然后它的生命周期应该由智能指针管理。
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.
No; if you only need it locally, then it should be an ordinary automatic object.
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.
如果您只是声明一个容器,其中充满了指向堆上分配的对象的指针,那么如果您不小心,很容易让容器超出范围,此时就会发生内存泄漏。这是因为容器仅拥有在容器中分配的类型的所有权。例如,对于 std::vector,向量将仅维护分配内存以包含一系列指针的所有权...它不会维护这些指针的对象的所有权正在指向。这只是因为它不能......容器如何知道它指向堆对象而不是其他对象?如果它指向一个堆对象,它怎么知道它是对该堆对象的唯一引用,并且它可以在必要时删除它而不是创建一堆悬空指针?现实情况是,由于 STL 容器不携带此类全局状态信息,因此它们不可能知道这些问题的答案,因此 STL 容器管理的唯一内存是它为其自己的对象分配的内存。控制。因此,当存储指针的容器超出范围时,用于分配指针的内存将被正确销毁,但容器本身不会对每个指针调用delete来释放每个指针所分配的对象。指向堆上。使用 std::shared_ptr作为 STL 容器的类型允许容器传递超出范围并删除为每个分配的
shared_ptr
分配的内存数组内。不过,由于共享_ptr 中存储了引用计数对象状态信息,一旦删除了对对象的最后一个引用,它本身就会正确地销毁它所管理的堆上的对象。因此,如果您有一个超出范围的 STL 容器,则该容器中的任何shared_ptrs
(它们所指向的对象的最后一个引用)都会正确地销毁堆上的对象,并且您不会因堆对象的指针丢失而导致一系列内存泄漏。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 calldelete
on each pointer to deallocate the object that each pointer was pointing to on the heap. Usingstd::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 eachshared_ptr
allocated within the array. Because of the reference-counting object-state information stored within ashared_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, anyshared_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.如果您只在本地需要它,则使用自动实例:
如果您需要返回并且
T
很重(或向量大得离谱),则使用shared_ptr
或指针向量(T
很重而且很小),否则按值返回,例如vector
,根据大小,也可以按值返回(I猜测很大程度上取决于调用者是什么打算用它来做)...If you only need it locally, then use an automatic instance:
If you need to return and
T
is heavy (or vector is ridiculously large), then use either theshared_ptr
or vector of pointers (T
is heavy and it's small), else return by value, for examplevector<int>
, depending on size, may as well return by value (I guess depends heavily on what the caller is going to do with it)...