c++ - 这是对花括号初始化列表的不安全使用吗？

Question

最近我的程序中出现了一个错误，这让我有点吃惊，但也许不应该，因为 C++(尤其是现代 C++)提供了大量的初始化类型。我有一个看起来像这样的类:

struct foo
{
    foo(const std::set<int> &values) { values_ = values; }

    set::set<int> values_;
};

构造 foo 时，通常最简单的方法是使用初始化列表指定内联值集(一个实例通常有 2-3 个在编译时已知的已知值)，就像这样:

auto f = std::make_shared<foo>({ 1, 2, 3 });

但是，我记得当我第一次写类 foo 时，上面的用法给我带来了编译时问题；我不记得确切的错误，但我发现显式调用 initializer_list 构造函数允许编译器正确推断如何处理参数，如下所示:

auto f = std::make_shared<foo>(std::initializer_list<int>({ 1, 2, 3 }));

这“有效”了很长时间，但我的应用程序最近遇到了一些不明显的随机崩溃。调试后发现将上面的改成:

auto f = std::make_shared<foo>(std::initializer_list<int>{ 1, 2, 3 });

(即从复制初始化更改为花括号初始化器)修复了该问题。这让我想到了这个问题:

Is copy construction of an initializer list as shown in the example above an unsafe practice? Does the lifetime of the values in the braced initializer not match the lifetime of the full enclosed expression?

这可能只是其他一些仍然存在的错误或某种编译器错误的症状(我使用的是 Apple clang v8.0)。

Answer 1

临时初始化列表应该持续到它们构造的语句结束，并且它们的生命周期会扩展它们包装的数组。

同时 make_shared<?>({1,2,3})预计不会工作(请参阅完美转发的缺陷)，您的代码的其余部分应该。如果您描述的更改实际上导致代码开始/停止工作，则说明您有一些内存损坏。

如果这很有可能是确定性的，则问题很可能是有人对堆栈中的对象有悬空引用，并且正在修改或读取它。当您更改构造初始化列表的方式时，堆栈上对象的布局会发生变化，并且会发生不同的行为(某些值非零或零并且分支以不同的方式进行，或者写入的内容无关紧要在一种情况下，在另一种情况下。

如果它是基于写入的内存损坏，设置内存断点并跟踪对该堆栈区域的所有访问(尽可能乏味)有时可以发现悬空指针所在的位置。