C++ shared_ptr 与 Python 对象

Question

据我所知，shared_ptr 的使用通常不鼓励使用，因为不小心使用它们会导致潜在的错误（除非你对显着的好处和仔细检查的设计有很好的解释）。

另一方面，Python 对象似乎本质上是 shared_ptrs（ref_count 和垃圾回收）。

我想知道是什么让它们在 Python 中运行良好，但在 C++ 中却存在潜在危险。换句话说，Python 和 C++ 在处理 shared_ptr 方面有什么区别，在 C++ 中不鼓励使用它们，但在 Python 中不会引起类似问题？

我知道例如Python 会自动检测对象之间的循环，从而防止在 C++ 中悬挂循环 shared_ptrs 可能导致的内存泄漏。

Answer 1

“我知道，例如 Python 会自动检测循环”——这就是使它们工作良好的原因，至少就“潜在错误”与内存泄漏有关而言。

除此之外，与 Python 程序相比，C++ 程序更常在严格的性能限制下编写（IMO 是不同的真实需求与一些相当虚假的经验法则差异的组合，但这是另一回事）。我使用的相当大比例的 Python 对象并不严格需要引用计数，它们只有一个所有者，unique_ptr 就可以了（或者就此而言是类类型的数据成员）。在 C++ 中（由编写您正在阅读的建议的人）认为值得利用性能优势和明确简化的设计。在 Python 中，这通常不被视为问题，您支付性能费用并保留稍后决定共享它的灵活性，毕竟不需要任何代码更改（我的意思是，除了获取比原始文件更有效的额外引用）。

顺便说一句，在任何语言中，共享的可变对象都有与之相关的“潜在错误”，如果您在不查看对象时忘记了哪些对象会更改或不会更改。我不仅仅指竞争条件：即使在单线程程序中，您也需要注意 C++ 谓词不应更改任何内容，并且您（通常）不能在迭代容器时对其进行变异。不过，我不认为这是 C++ 和 Python 之间的区别。相反，在某种程度上，您应该对 Python 中的共享对象也稍有警惕，并且当您激增对对象的引用时，至少要了解您这样做的原因。

那么，关于您链接到的问题中的问题列表：

• cyclic references -- 如前所述，Python 卷起袖子，找到它们并释放它们。由于与语言的设计和特定用途有关的原因，循环中断垃圾收集很难在 C++ 中实现，尽管并非不可能。
• creating multiple unrelated shared_ptrs to the same object -- 在 Python 中无法进行模拟，因为引用计数器不向用户开放以搞乱。
• Constructing an anonymous temporary shared pointer -- 在 Python 中不会出现，在 Python 中不存在内存泄漏的风险，因为不存在对象存在的“间隙”，但如果它变得未引用，则还不能被收集。
• Calling the get() function to get the raw pointer and use it after the pointed-to object goes out of scope -- 好吧，如果你正在编写 Python/C，你可能会搞砸这个，但不是纯 Python。
• Passing a reference of or a raw pointer to a shared_ptr should be dangerous too, since it won't increment the internal count -- 在 Python 中没有任何方法可以添加引用而不需要语言处理引用计数。
• we passed 'this' to some thread workers instead of 'shared_from_this'——换句话说，忘记在需要时创建shared_ptr。在 Python 中无法做到这一点。
• most of the predicates you know and love from <functional> don't play nicely with shared_ptr -- Python 引用计数是如此内置于运行时（或者我想准确地说：垃圾收集是如此内置于语言设计中）以至于没有库无法应对它。李>
• Using shared_ptr for really small objects (like char short) could be an overhead -- Python 中存在问题，Python 程序员通常不会为此出汗。如果您需要一个“原始类型”数组，那么您可以使用numpy 来减少开销。有时 Python 程序会耗尽内存，您需要对其做点什么，这就是生活 ;-)
• Giving out a shared_ptr< T > to this inside a class definition is also dangerous. Use enabled_shared_from_this instead——这可能并不明显，但这又是“不要为同一个对象创建多个不相关的shared_ptr”。
• You need to be careful when you use shared_ptr in multithread code -- 在 Python 中也可以创建竞争条件，这是“共享可变对象很棘手”的一部分。

这主要是因为在 C++ 中你必须明确地做一些事情来获得引用计数，如果你不要求它，你就不会得到它。这提供了 Python 没有为程序员提供的几个错误机会，因为它只是为你做的。如果您正确使用shared_ptr，那么除了存在不与之合作的库之外，C++ 中也不会出现这些问题。出于这些原因而谨慎使用它的人基本上是在说他们害怕他们会错误地使用它，或者至少比他们会误用某些替代品更害怕。许多 C++ 编程都在相互交换不同的潜在错误，直到你想出一个你认为自己有能力执行的设计。此外，它具有“不为不需要的东西买单”作为设计理念。在这两个因素之间，如果没有非常好的解释、显着的好处和经过仔细检查的设计，您就不会做任何事情。 shared_ptr 也不例外 ;-)

Answer 2

据我所知，shared_ptr 的使用通常不鼓励使用，因为不小心使用它们会导致潜在的错误（除非你对显着的好处和仔细检查的设计有很好的解释）。

我不会同意的。除非您有充分的理由不这样做，否则倾向于普遍使用这些智能指针。

shared_ptr 在 C++ 中不鼓励使用，但在 Python 中不会引起类似问题？

好吧，我不知道你最喜欢的大型信号处理框架生态系统，但GNU Radio 将 shared_ptrs 用于他们的所有块，这是 GNU Radio 架构的核心元素。实际上，块是类，具有private 构造函数，只能由friend make 函数访问，该函数返回shared_ptr。我们在这方面没有遇到任何问题——GNU Radio 有充分的理由采用这样的模型。现在，我们没有一个地方可以让用户尝试使用已释放的块对象，也没有一个块被泄露。不错！

此外，我们对一些 C++ 类型使用 SWIG 和网关类，这些类型不能仅用 Python 类型很好地表示。所有这些在 C++ 和 Python 双方都非常有效。事实上，它工作得非常好，我们可以将 Python 类用作 C++ 运行时中的块，包装在 shared_ptr 中。

此外，我们从未遇到过性能问题。 GNU Radio 是一个高速率、高度优化、高度多线程的框架。