什么时候要从原始指针构造共享指针？
多亏了std::make_shared，我想知道，作为原始指针的std::shared_ptr的构造函数是否有任何值，除了与遗留/库代码进行接口时(例如在存储工厂的输出时)。
- 还有其他合法的用例吗？
- 避免构造函数是合理的建议吗？
- 即使是将代码检查放到适当的位置，以警告程序员何时使用它，也是如此吗？
- 同样的准则(不管是什么)是否适用于
shared_ptr<T>::reset(T*)？
关于代码检查:我知道与遗留/库代码的接口很常见，所以自动化的代码检查可能会有问题，但在大多数情况下，到目前为止，我还是宁愿使用unique_ptr，我也不是在谈论在-Wall上弹出的编译器警告，而是在代码评审期间使用静态代码分析的规则。
我的动机：
说“不要使用std::shared_ptr<T>(new T(...))__，总是喜欢std::make_shared<T>(...)__”比较容易(我认为这是正确的建议？)。但是，我想知道这是不是一般的设计味道，是否必须从原始指针创建shared_ptr，甚至--尤其是--如果对象不仅仅是通过new创建的，因为对象本来应该是作为“共享”或“唯一”对象创建的。
Stack Overflow用户
发布于 2015-07-28 09:53:01
许多答案至少提供了一个独特的方面，所以我决定做一个简单的回答。信用归于“Niall”、“Chris”、“utnapistim”、“isanae”、“Markus”和(代理) Scott。
您可能不希望/可能无法使用make_shared的原因是：
- 您必须使用自定义删除器和/或自定义分配器/新运算符。
这可能是最常见的原因，特别是当与第三方库接口时。在某些情况下，
std::allocate_shared可能会有所帮助。 - 如果内存是一个关注点，并且您的指针往往比对象更弱。 由于托管对象是在与控制块相同的内存块上创建的，因此在最后一个弱指针也被销毁之前，内存无法释放。
- 如果您有一个私有构造函数，例如只有一个公共工厂函数。
在这种情况下，让
make_shared成为朋友并不是一个可行的解决方案，因为实际的构造可能发生在某些辅助函数/类中。
关于代码检查，上面列出的异常可能太多，无法自动检查“只要有可能就使用make_shared”准则，以及将违反该准则的行为本身称为设计气味。
作为一个亮点，即使库需要自定义分配程序和分发程序函数，而且我们不能/不想使用std::allocate_shared，我们也可以使自己版本的make共享，至少封装分配和删除调用，并增加异常安全性(尽管它很可能没有提供单一的分配优势)。
https://stackoverflow.com/questions/31605357
复制相似问题
腾讯云开发者
