如何防止任何人窃取我的shared_ptr？
因此，我使用 boost::shared_ptr 来获得它提供的所有各种引用计数优势——显然，对于初学者来说是引用计数，而且还具有复制、分配并因此存储在 STL 容器中的能力。
问题是，如果我将它传递给一个“恶意”函数或对象，该对象可以保存 ptr，然后我将永远无法在外部函数或对象很好地放弃其所有权的情况下取消分配它。
最终，我尝试保持对象所有权的明确性。我通过让所有者将唯一的shared_ptr保留给对象来实现这一点，而“来宾”对象只将weak_ptr存储给对象。
我真的不想要shared_ptr的“共享”部分，但我需要使用shared_ptr才能创建weak_ptrs。我想使用scoped_ptr，但它非常有限，因为你无法复制它。你不能将它存储在容器中，你不能从中借出weak_ptr，并且你不能将所有权转移给新的管理者。
解决办法是什么？
So, I use boost::shared_ptr for all the various reference-counting benefits it provides -- reference counting for starters, obviously, but also the ability to copy, assign, and therefore store in STL Containers.
The problem is, if I pass it to just one "malicious" function or object, the object can save the ptr and then I'll never be able to de-allocate it without the foreign function or object nicely relinquishing its ownership.
Ultimately, I try to keep object ownership explicit. I accomplish this by having the owner keep the only shared_ptr to the object, and "guest" objects only store weak_ptrs to the object.
I really don't want the "shared" part of shared_ptr, but I'm required to use shared_ptr in order to make weak_ptrs. I want to use scoped_ptr, but it's extremely limited since you can't copy it. You can't store it in a container, you can't lend out weak_ptrs from it, and you can't transfer ownership to a new manager.
What's the solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
将其设为私有并提供一个外观来执行所需的任何操作。没有人看到指针。我想那时你甚至不需要shared_ptr。
Make it private and provide a facade to do whatever operations needed. Nobody ever sees the pointer. I guess that at that point you would not even need a shared_ptr.
不要传递 boost::shared_ptr 对象...即使您在内部使用 boost::shared_ptr 存储该对象，您也应该确保函数通过常量引用而不是共享指针的副本获取您的对象。由于您需要取消引用共享指针才能将对象传递给通过 const 引用传递的函数，因此您将知道它是否遵循该协议。
Don't pass around the boost::shared_ptr object... even if you store the object, internally, using a boost::shared_ptr, you should make sure that functions take your object by constant reference rather than a copy of the shared pointer. Since you would need to dereference the shared pointer in order to pass the object to a function that passes by const reference, you will know whether it follows that protocol or not.
正如您在问题中所描述的那样，对来宾对象使用weak_ptr就足够了。否则你会遇到死指针的问题。
我会考虑重新构建应用程序以删除“恶意”函数/对象或至少修复它们的行为。
It's good enough to use weak_ptr for guest objects, as you described in question. Otherwise you will have a problem with dead pointers.
I would consider to do application rearchitect to remove "malicious" functions/objects or at least fix their behavior.
您可以扩展shared_ptr boost类并覆盖delete以强制删除指针。
问题实际上是，如果库没有释放或释放shared_ptr，那么它可能会在某个时候引用它。此时您的应用程序将带有 SIGSEGV。
我认为这完全使共享指针的目的失效。
最佳解决方案是修复该库。
其他解决方案，使用 AOP 在您正在调用的库函数退出时删除指针。这仍然有可能被打破。
You could extend the shared_ptr boost class and override delete to force delete the pointer.
The issue really is that, if the library is not releasing or freeing the shared_ptr then its likely to refer to it some time. At this time your application will fall with a SIGSEGV.
I think it totally invalidates the purpose of shared pointers.
The best solution is to fix the library.
Other solution, use AOP to delete pointer on exit of the library function you are calling. This is still likely to break.
对于你所描述的情况确实没有什么好的解决办法。
您不能使用 auto_ptr，因为您没有转移所有权。
如果您可以保证所有者比引用寿命更长，我建议在所有者中使用scoped_ptr/store by value，然后将原始指针或引用传递给需要它的人。
如果引用的寿命比所有者长（并且需要优雅地通知引用），则必须使用shared_ptr/weak_ptr。但是，正如您所说，您无法阻止任何类/函数锁定weak_ptr并“阻止”释放。但是，在接口中，不要传递shared_ptr，而是传递weak_ptr。它的强度只是约定俗成的，但它说“不要坚持这个，它可能会消失”。
There's really no good solution for what you're describing.
You can't use auto_ptr because you're not transferring ownership.
If you can guarantee the owner outlives the references, I'd recommend using a scoped_ptr/store by value in the owner and then passing a raw pointer or reference to those that need it.
If references can outlive the owner (and the references need to be gracefully notified), you have to use shared_ptr/weak_ptr. But, as you stated, you cannot prevent any class/function from locking the weak_ptr and "preventing" deallocation. But, in the interface, do not pass the shared_ptr, pass the weak_ptr. It's only as strong as a convention, but it says "don't hold onto this, it may go away".
如果您想在所有者/拥有的范例中处理对象，我建议您执行类似 Qt 的操作。
setOwner(Object * Owner)方法设置所有者，并让该方法确保所有者对象收到有关新子项的通知。需要注意的事项：
If you want to handle your objects in that owner/owned paradigm I recommend doing something like Qt.
setOwner(Object * owner)method to set the owner and have that method make sure that the owner object is notified about the new child.Things to watch out for: