c++ - shared_ptr 的原始指针构造函数是错误的吗？

Question

事后看来，给定 make_shared，shared_ptr 是否会有一个采用原始指针的构造函数，如果它是在 C++11 中引入的？

是否有支持此构造函数的有力论据或用例？

它可以避免使用 make_shared 的 exception-safety 和 memory allocation/performance advantage 的有据可查的陷阱。

我相信通过 make_shared 要求构建 shared_ptr 的另一个好处是它可以是引擎盖下的单个指针，降低其内存使用并使诸如 atomic_compare_exchange 之类的东西成为更简单(并且可能更有效)。 (见 presentation from C++Now )

我知道 shared_ptr 基本上是一个 intrusive_ptr(对象和控制 block 合并)将缺少当前 std::shared_ptr 所具有的功能。喜欢:

1. 从控制 block 中单独释放对象的能力(如果你有长期存在的 weak_ptrs，这很好)

2. 与提供原始指针的库的兼容性以及释放它们的责任

3. 使用自定义删除器(或无删除器，对于非拥有指针)保存任意资源的能力

4. 在使父对象保持事件状态的同时指向子对象(例如，成员)的能力。

我的建议是，这些功能可能使用得不够普遍(或者在将其用作 RAII 包装器的情况下)可能不是最合适的，以保证额外费用:

1. 指向控制 block 的单独指针
2. (可能)更复杂的 atomic_compare_exchange 逻辑，可能不值得。

在 C++98 世界(引入 shared_ptr 的地方)中，make_shared 不太实用且用户友好性较低(缺少完美转发需要引用包装器，缺少可变参数模板使实现变得笨拙)。

Answer 1

In hindsight, given make_shared, would shared_ptr have a constructor that takes a raw pointer had it been introduced with C++11?

如果不控制对象的分配怎么办？如果您需要使用自定义删除器怎么办？如果您需要列表初始化而不是括号怎么办？

make_shared 不会处理这些情况。

此外，如果您正在使用 weak_ptr，则通过 make_shared 分配的 shared_ptr 不会释放任何内存，直到所有 weak_ptr 也被销毁。因此，即使您有一个普通的共享指针，但上述情况均不适用，您可能仍然更喜欢原始指针构造函数。

还有一种情况是，如果您的类型为 operator new 和 operator delete 提供重载。这些可能使其不适合 make_shared，因为这些重载不会被调用 - 并且它们的存在可能是有原因的。