std::shared_ptr<T>：指向 T 的右值指针的隐式构造函数答案

【问题标题】：std::shared_ptr<T>: implicit constructor for rvalue pointer to Tstd::shared_ptr<T>：指向 T 的右值指针的隐式构造函数
【发布时间】：2014-09-26 07:58:11
【问题描述】：

我非常支持让std::shared_ptr<T> 构造函数接受T * 显式的想法。当您查找堆损坏的原因时，它有助于挽救不眠之夜。 Scott Meyers 对此给出了很好的解释。

但是...如果我给它一个rvalue 指针不是很明确吗？我可以这样做：

/// (1)
std::shared_ptr<T> t = new T;

或

/// (2)
T * giveaway = new T;
std::shared_ptr<T> t = std::move(giveaway);

或者现实生活中更痛苦的案例

/// (3)
void foo(std::shared_ptr<T> t);
/// ...
foo(new T);

对我来说，所有这些情况都足够明确。

案例 (1) 是 prvalue，我不可能因为两个指针而搞砸自己。至少不超过使用：

std::shared_ptr<T> t{new T};

案例 (2) 非常明确。一致认为，在您移动某些东西后，它的值变得未定义。所以使用它完全取决于你。

案例 (3) 又是一个rvalue。

(Q1) 这是标准委员会的疏忽？

（Q2）这是有原因的吗？

(Q3) 接受rvalue 的隐式构造函数是否有机会出现在 C++14 中？

【问题讨论】：

至 Q3：C++14 是官方的，这并没有改变。
我错过了什么吗？为什么不使用 make_shared？
@MarcoA。同样的原因，我们不在将文字传递给接受std::string的函数的任何地方都使用std::string("literal")。很简单。
好吧，虽然它可能代表 case 2，但 case 1 和 case 3 实际上使用 make_shared 更高效、更安全

标签： c++ c++11 shared-ptr rvalue

【解决方案1】：

即使给出右值也不允许从原始指针隐式构造智能指针，这是有原因的：

不安全。

void foo(std::shared_ptr<T> t);
char buffer[42];
foo(buffer+7); // buffer+7 is a rvalue, and would implicitly convert!

因此，对于您问题的其他两个部分：

这不是委员会的疏忽。

和

它不会出现在未来的 C++ 标准中（无论如何，C++14 已经出来了，它没有出现）。

【讨论】：