我记得 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++ 编译器怎么样？
有没有人在他的特定平台上观察到这种行为？
最佳答案
这不是平台问题，而是异常安全问题。因此，您实际问题的答案是:所有这些平台都可能出现该问题。
内存泄漏问题是由两件事引起的:
- 使用
new分配内存可能会抛出bad_alloc - 函数参数的计算顺序未指定。
boost::shared_ptr 的文档很好地捕获了它 here
一般问题有更详细的处理here (GOTW)
它可能“罕见”的原因是因为获得 bad_alloc 实际上并不常见，但如果要避免内存泄漏，您的代码必须安全地处理这种可能性。
(我说“可能”展示它 - 我没有检查如果 new 失败，它们是否都抛出 bad_alloc...)
关于c++ - 在什么平台上 func(shared_ptr(...), shared_ptr(...)) 真的很危险？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18075152/