c++ - 确保用户使用 shared_ptr 而不是常规 ptr 的正确方法是什么？

Question

在我的类中，构造函数是私有的，我添加了一个静态方法“CreateMyClassPtr”，它使用构造函数并返回它的 share_ptr。

它是正确的实现吗？

你认为我什至必须确保它shared_ptr会被使用吗？我应该把它留给用户来决定吗？

Answer 1

如果您没有保留它的任何副本，但您希望用户使用删除指向的对象，delete那么您可以std::auto_ptr按值返回 a。它不添加任何依赖项（auto_ptr是标准的一部分），它使您的界面清楚地传达了对象需要被deleted 的要求。

如果用户愿意，他们可以release手动操作指针并执行操作，或者将其移动到他们的共享智能指针框架中。

Answer 2

元素真的共享吗？也就是说，在创建之后，您是出于自己的目的保留指向对象的指针，还是只是为了避免用户内存泄漏而这样做？

如果内存实际上没有共享，我不会使用shared_ptr. 请注意，通过使用shared_ptr作为您的返回类型，您会强制使用动态分配和智能指针的特定实现，但会限制堆栈用于您的类型和其他可能更合适的智能指针类型（您无法提取来自共享指针的成员资格）

如果您真的想确保调用不会泄漏（也就是说，如果用户调用您的函数，则返回的内存将被“以某种方式”处理，您可以使用std::auto_ptror boost::unique_ptr（最后一个即使在 C++0x 中也是不标准的） . 两种解决方案都允许调用代码从智能指针中提取指针并使用不同的内存管理方法（即使在某些情况下可能很麻烦）。

struct type {
   std::auto_ptr<type> create(); 
};
std::auto_ptr<type> ap = type::create();
std::shared_ptr<type> sp( type::create().release() );
type::create(); // will not leak memory
type *rp = type::create().release(); // user specifically requested a raw pointer!

Answer 3

那会起作用的，是的。但是，你确定你需要它吗？在某些情况下这样做是合适的，但是当你这样做时，你实际上是在限制你的选择。用户可能想要使用其他形式的智能指针，更不用说当您以这种方式隐藏构造函数时，您正在消除基于堆栈的分配作为选项。

Answer 4

如果您要将您的类公开给客户，那么不要强迫他们使用共享指针。他们知道他们创建了一个对象并负责删除它。

然后他们可以很容易地写

myfavorite::api::shared_ptr<Class> object(Class::create());

或者

std::auto_ptr<Class> object(Class::create());