C++ 使用 C++11 (std::shared_ptr) 分配 shared_ptr:将 shared_ptr 初始化为临时变量是否仍然不好？

Question

我正在阅读 this answer作者指的是boost best practices其中说:

Avoid using unnamed shared_ptr temporaries to save typing; to see why this is dangerous, consider this example:

void f(shared_ptr<int>, int); 
int g();

void ok() {
    shared_ptr<int> p(new int(2));
    f(p, g());
}

void bad() {
    f(shared_ptr<int>(new int(2)), g());
}

The function ok follows the guideline to the letter, whereas bad constructs the temporary shared_ptr in place, admitting the possibility of a memory leak. Since function arguments are evaluated in unspecified order, it is possible for new int(2) to be evaluated first, g() second, and we may never get to the shared_ptr constructor if g throws an exception. <...>

The exception safety problem described above may also be eliminated by using the make_shared or allocate_shared factory functions defined in boost/make_shared.hpp. These factory functions also provide an efficiency benefit by consolidating allocations.

我想我会开始使用 make_shared，但我想知道这条建议是否仍然适用于 C++11 shared_ptr。我问是因为我真的不完全理解为什么抛出 g() 会阻止 ctor 被调用。

Answer 1

是的，C++11 的 shared_ptr 以同样的方式工作。

I ask because I don't really fully understand why it is that a throwing g() would prevent the ctor from getting called.

你不明白什么？这是一个操作顺序问题，标准不要求特定的顺序。让我们将语句解压缩为一系列表达式:

auto __temp = new int(2);
auto &&__temp2 = g();
auto __temp3 = shared_ptr<int>(__temp);

你现在看到问题了吗？如果 g 抛出异常，那么 __temp3 将永远不会被初始化。因此，__temp 将被泄露。

C++ 标准不要求语句以这种方式解包。但它也不禁止。编译器可以自由地按照它认为合适的方式对这些独立的表达式进行排序。