c++ - 在什么平台上 func(shared_ptr(...), shared_ptr(...)) 真的很危险？

Question

我记得 Scott Meyers 教我的

func(shared_ptr(new P), shared_ptr(new Q));

是危险的，因为(如果我没记错的话)内存分配、引用计数(构造)和分配给 顺序>函数参数 允许leak (理论上？)在极少数情况下出现。为了防止这种情况应该将 shared_ptr 封装在函数调用中，例如在 make_shared() 中。

func(make_shared<P>(), make_shared<Q>());

这是一些 discussion关于它。

我想知道是否有(当前)编译器在该领域，在某些系统上确实可能在某些错误情况下留下一些漏洞？还是那些时代已经过去了，或者它们只是理论上的？

最有趣的是知道其中是否存在该问题:

• g++ 4.x 或 g++ 2.95，在 Linux i386、x64、ARM、m68k 或任何 Windows 上
• i368、x64 或 ARM 上的 Visual C++
• Linux 或其任何平台上的 Clang/LLVM
• Sun 或 IBM、HP-UX 上/来自 Sun 或 IBM 的 C++ 编译器怎么样？

有没有人在他的特定平台上观察到这种行为？

Answer 1

这不是平台问题，而是异常安全问题。因此，您实际问题的答案是:所有这些平台都可能出现该问题。

内存泄漏问题是由两件事引起的:

• 使用 new 分配内存可能会抛出 bad_alloc
• 函数参数的计算顺序未指定。

boost::shared_ptr 的文档很好地捕获了它 here

一般问题有更详细的处理here (GOTW)

它可能“罕见”的原因是因为获得 bad_alloc 实际上并不常见，但如果要避免内存泄漏，您的代码必须安全地处理这种可能性。

(我说“可能”展示它 - 我没有检查如果 new 失败，它们是否都抛出 bad_alloc...)