使用std::initializer_list存储无尺寸字符串字面量数组的生命周期问题

我正在探索无需附带尺寸信息即可存储任意类型字面量数组的实现方案，目前已梳理出数种实现思路，每种思路都存在待确认的问题。本次测试选用std::initializer_list作为实现载体，而非基于std::array做模板化封装。

说明：以下展示的均为简化测试用例，实际业务场景中的类可能包含额外成员、额外模板参数，或是存在必须显式指定的模板参数。

对应基础测试代码如下：

struct B {
    std::initializer_list<const char*> a;
    int b;
};

// 问题验证用辅助函数
constexpr std::initializer_list<const char*> get1() {
    // 待确认：此处返回的字符串字面量生命周期是否安全？
    return {"1", "2", "3"};
}

由于要处理的是存储在程序代码段中的字面量值，我才考虑直接使用initializer_list对象，没有选std::array模板化方案的原因如下：

• 虽然initializer_list本身不持有内部元素的所有权，但列表中存储的字面量值生命周期贯穿程序整个运行周期，不会随作用域退出失效
• 使用时无需显式指定列表尺寸，不管列表长度是多少，都不需要额外编写适配的模板代码
• 这个方案唯一的缺点是initializer_list不原生支持下标运算符，相关代码写起来会稍显繁琐

这个巧用初始化列表的思路来自IRC交流，基于该方案可以实现如下常规用法：

auto b = B{{"1","2","3"}};
auto b = B{get1()};

std::cout << b.a.begin()[2] << ", size: " << b.a.size() << std::endl;

for (auto& e: b.a) { std::cout << e << std::endl; }

auto l = [](const char* s) { return !strcmp(s, "2"); };
auto r = std::find_if(begin(b.a), end(b.a), l);
std::cout << "result: " << *r << std::endl;

• 初始化列表的底层存储是否直接对应字符串字面量？
• 既然字符串字面量是全局存储的，那这里用到的初始化列表是否在程序整个运行周期内都始终有效？
• 以下两种初始化写法是否存在悬垂指针风险？

  auto b = B{{"1","2","3"}};
  auto b = B{get1()};
  

• 如果上述写法不存在悬垂风险，要怎么消除对应的编译警告？

逐个对应解答如下：

1. 初始化列表底层存储是否直接对应字符串字面量
   不是。你定义的std::initializer_list<const char*>的底层存储是一块临时的const char*类型数组，数组里存的每个元素是指向对应字符串字面量首地址的指针。字符串字面量本身存储在程序只读数据段，和初始化列表的底层数组是两块独立的内存，不存在直接对应关系。

2. 初始化列表是否整个运行周期都有效
   不能一概而论，和初始化列表的创建上下文直接相关：

• 按C++标准的默认规则，普通场景下创建的std::initializer_list，其底层数组的生命周期和创建它的完整表达式绑定，表达式执行结束后底层数组就会销毁，不会一直有效。
• 只有当std::initializer_list是常量表达式的一部分时（比如constexpr函数返回、constexpr变量初始化），编译器才会把它的底层数组提升到静态存储区，这时候它的生命周期才会和程序运行周期一致，全程有效。
  注意：不要混淆字符串字面量的生命周期和初始化列表底层数组的生命周期——哪怕字符串字面量一直存在，如果存这些指针的初始化列表底层数组销毁了，你根本拿不到这些指针，访问行为就是未定义的。

3. 两种初始化写法的悬垂风险

• auto b = B{get1()};：无悬垂风险。因为get1()是constexpr函数，返回的initializer_list属于常量表达式范畴，它的底层存指针的数组是静态分配的，程序退出前都不会销毁，内部指针指向的字符串字面量也全程有效，不存在悬垂。
• auto b = B{{"1","2","3"}};：默认场景下有悬垂风险。如果这行代码没有在常量求值上下文里（比如没有把b声明为constexpr），初始化完成后，创建临时initializer_list的完整表达式就结束了，它的底层数组会被销毁，b.a持有的迭代器指向已经释放的内存，访问属于未定义行为。如果改成constexpr auto b = B{{"1","2","3"}};，整个初始化过程是常量求值，底层数组会被提升到静态存储，就没有悬垂风险了。

4. 编译警告消除方法
   不要直接用编译参数屏蔽警告，先从代码层面规避风险，警告自然会消失：

• 所有需要长期持有initializer_list的场景，优先用constexpr辅助函数返回（类似你写的get1()），或者直接把持有该列表的变量声明为constexpr，从根源上保证底层数组是静态存储的，不存在生命周期问题。
• 新版本的GCC 12+、Clang 15+已经能准确识别constexpr场景下initializer_list的静态生命周期，不会误报；如果是旧版本编译器对直接列表初始化的constexpr场景误报，把初始化逻辑挪到constexpr辅助函数里返回即可，编译器对函数返回值的生命周期识别准确率更高。
• 绝对不要在没有确认生命周期安全的情况下，用强制类型转换或者编译指令去屏蔽这类警告，很容易掩盖真实的悬垂问题。

内容的提问来源于stack exchange，提问作者user19087