随着shared_ptr包含在c++11中，你可以实现一个半垃圾收集的环境。（inflective？）使用会沿着一些缺点吗？
我可以想象一个类模型，在其中创建一个类，并在类的末尾键入def作为shared_ptr以简化语法。
/////////////////
//// MyClass ////
/////////////////
#include <memory>
class MyClass {
public:
Myclass();
};
typedef std::shared_ptr<MyClass> SharedMyClass;
///////////////////////
//// Example Class ////
///////////////////////
class Example {
public:
Example(): myClassObject(new MyClass()) {}
private:
SharedMyClass myClassObject;
};
3条答案
按热度按时间2mbi3lxu1#
当然也有缺点：你需要额外的内存来维护一个引用计数，并且每次你复制或销毁一个
shared_ptr示例时，这个引用计数都必须增加和减少。如果你的程序使用多线程，那么引用计数的操作必须以线程安全的方式完成，这会增加一些额外的开销，其大小取决于实现。这种开销是否会对程序产生负面影响取决于程序的细节。一般来说，您应该只对真正需要共享的资源使用
std::shared_ptr，因为哪个对象最后需要它们可能有点随意。在其他情况下，单点所有权通常更容易维护，因为您确切地知道每个资源将存活多长时间。此外，您需要注意
std::shared_ptr不是对象生存期管理的万能药，特别是，如果您有两个对象，每个对象拥有另一个对象的std::shared_ptr，则对象具有循环所有权，并且永远不会被自动删除，除非您首先通过在其中一个对象上调用reset()来打破循环。eiee3dmh2#
另一件值得一提的事情是，在使用
std::shared_ptr设计API时需要非常小心。与原始指针相比，它的明显优势是自动内存管理（循环所有权），但其他问题仍然存在。当资源被共享时，你（在某种程度上）放弃了对代码的控制和推理能力。
你改变了对象，改变会反映到整个系统中。系统越大，影响就越不明显，而且很难证明这样做实际上是安全的。Sean Parent经常说，共享ptr实际上和全局变量一样好。
kqqjbcuj3#
如果性能很重要，我就不会使用std：：shared_ptr。例如，用真实的指针排序数组比用共享指针排序快5倍。
另一方面，共享指针并不能避免循环引用时垃圾泄漏的所有麻烦。当然，这可以通过weak_ptr来解决，但我的意思是，共享指针也需要小心处理。
对于静态元素，我更喜欢使用shared_ptr，因为静态元素不会被类的析构函数删除。