关于延迟动态初始化的问题

Question

考虑basic.start.dynamic部分中的示例，即：

// - File 1 -
#include "a.h"
#include "b.h"
B b;
A::A(){
  b.Use();  //#1
}

// - File 2 -
#include "a.h"
A a;

// - File 3 -
#include "a.h"
#include "b.h"
extern A a;
extern B b;

int main() {
  a.Use();  //#2
  b.Use();
}

下面的 cmets 是：

但是，如果 a 在 main 的第一条语句之后的某个时间点被初始化，则 b 将在其用于 A​::​A 之前被初始化。

我不明白为什么 b 在使用 A​::​A 之前会被保证初始化，而当 a 在 main 的第一条语句之后的某个时间点被初始化时。按照规定：

basic.start.dynamic#4

具有静态存储持续时间的非局部非内联变量的动态初始化是在main的第一条语句之前排序还是延迟，由实现定义。 如果它被延迟，它强烈发生在任何非初始化之前 - 使用与要初始化的变量在同一翻译单元中定义的任何非内联函数或非内联变量。

basic.start.dynamic#3

非初始化 odr-use 是 odr-use ([basic.def.odr]) 不是由非本地静态或线程存储持续时间变量的初始化直接或间接引起的 .

我能理解的是，当初始化被推迟时，变量a应该在变量a的odr-use(non-initialization odr-use)之前初始化，在标记的地方与#2。但是我无法理解的是，评论说 b 将在其用于 A​::​A 之前被初始化。 IIUC，函数A::A 的调用是变量a 初始化的一部分，因此变量b 在#1 的odr 使用不是非初始化odr 使用，因为它是由非局部静态或线程存储持续时间变量的初始化直接或间接引起。我认为它只能说变量b保证在#2之前被初始化，为什么评论说b将在其用于A之前被初始化​::​A ?如何解读这个例子？

Answer 1

从句的演变

有问题的（非规范）示例可以追溯到标准的 C++98 版本，但托管子句中的（规范）语言在 C++17 中发生了更改。

C++98：

3.6.2 非本地对象的初始化[basic.start.init]

3 - 命名空间范围对象的动态初始化（[交叉引用]）是否在 main 的第一条语句之前完成是实现定义的。如果初始化延迟到 main 的第一个语句之后的某个时间点，它应该发生在第一次使用与要初始化的对象相同的翻译单元中定义的任何函数或对象之前。 ^{[关于副作用的脚注]} [示例如下]

C++03 有同样的文字。 C ++ 11删除了交叉引用并将“命名空间范围的对象”替换为“具有静态存储持续时间的非局部变量”，“对象”替换为“变量”，以及“使用”替换为“odr-use”，但我会提出该条款的含义没有改变。 C++14 没有改变。

该语言随后由P0250R3 更改，于 2017 年 3 月发布并转录为标准草案，正好赶上 C++17。 P0250R3 增加了non-initialization odr-use 的定义，并修改了子句以引用该定义，同时还用线程感知术语（sequenced before）表达了事件之间的关系, 强烈发生在等之前），并添加了关于避免死锁的注释。

从那时起，关于避免死锁的说明已被修改为推荐做法。

措辞改变的动机

幸运的是，P0250R3 包含了动机的讨论。在顺序程序的并行初始化部分，我们读到：

目前，我们非常明确地允许静态构造函数在 main 启动后运行，而不管其他线程是否启动。这似乎是出于支持的意图，例如引用函数符号时延迟加载动态库，如 Posix 系统上的 RTLD_LAZY。即使静态命名空间范围的构造函数在库加载时立即运行，库也可能在 main 启动后隐式加载。

还有：

SG1 通常认为应避免使用静态命名空间范围的构造函数 [...] 我们决定将此类构造函数限制在现有线程中，这似乎与已知实现一致。

例子的正确性。

我认为这个例子一直是不正确的。

在 C++98 中，该示例是不正确的，因为该版本标准中的规范性措辞导致了循环性。假设我们扩充示例以在与 a 的定义相同的 TU 中定义构造函数 B::B：

// - File 2 -
#include "a.h"
A a;
B::B() {
   a.Use();
}

现在根据 C++98，a 的（动态）初始化发生在第一次调用 B::B 之前，并且b 的初始化发生在第一次调用 A::A 之前。但是a的初始化需要调用A::A，b的初始化需要调用B::B。所以我们有一个循环回归。

P0250R3 中的措辞更改（将 odr-use 更改为 non-initialization odr-use）打破了这种循环，代价是使示例变得荒谬。但后来它总是坏掉。这就是 SIOF，可以通过 Construct on First Use 习惯用法或使用辅助对象（例如 ios_base::Init）来避免。

实施实践

我将示例（带有循环性）编译成一个（Linux，ELF；CentOS 7.8）共享对象，在使用dlopen 输入main 后加载到程序中。恰好a 和b 之一在未初始化状态下被odr 使用，该状态取决于链接顺序。

这表明对non-initialization odr-use的措辞变化反映了实施实践。不幸的是，该标准现在包含一个明显不正确的示例，但由于示例和注释是非规范性的，这有问题但不是致命的。