c++ - std::optional<>::emplace() 是否会使对内部值的引用无效？

Question

考虑以下片段(假设 T 是平凡可构造和平凡可破坏的):

std::optional<T> opt;
opt.emplace();
T& ref = opt.value();
opt.emplace();
// is ref guaranteed to be valid here?

来自 the definition of std::optional我们知道包含的实例保证在 std::optional 容器内分配，因此我们知道引用 ref 将始终引用相同的内存位置。是否存在指向对象被销毁并再次构造后该引用将不再有效的情况？

Answer 1

C++20 有如下规则，[basic.life]/8:

If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if the original object is transparently replaceable (see below) by the new object. An object o₁ is transparently replaceable by an object o₂ if:

• the storage that o₂ occupies exactly overlays the storage that o₁ occupied, and
• o₁ and o₂ are of the same type (ignoring the top-level cv-qualifiers), and
• o₁ is not a complete const object, and
• neither o₁ nor o₂ is a potentially-overlapping subobject (6.7.2), and
• either o₁ and o₂ are both complete objects, or o₁ and o₂ are direct subobjects of objects p₁ and p₂ , respectively, and p₁ is transparently replaceable by p₂.

这表明只要T不是 const 限定的，破坏了 T在 std::optional<T> 里面然后重新创建它应该导致对旧对象的引用自动引用新对象。正如评论部分所指出的，这是对旧行为的更改，取消了 T 的要求。不得包含 const 限定或引用类型的非静态数据成员。 (编辑:我之前断言更改是追溯性的，因为我将它与 C++20 中的不同更改混淆了。我不确定 N4858 中指示的 RU 007 和 US 042 的决议是否具有追溯性，但我怀疑答案是肯定的，因为需要更改来修复涉及标准库模板的代码，这些模板可能不是打算从 C++11 到 C++17 被破坏。)

但是，我们假设新的 T “在 [旧] 对象占用的存储被重用或释放之前”创建对象。如果我正在编写标准库的“对抗性”实现，我可以将其设置为 emplace调用在创建新的 T 之前重用底层存储目的。这将防止旧的 T对象被新对象透明地替换。

实现如何“重用”存储？通常，底层存储可以这样声明:

union {
    char no_object;
    T object;
};

当 optional 的默认构造函数时被称为，no_object已初始化(值无关紧要)¹。一个emplace()调用检查是否有 T是否反对(通过检查此处未显示的标志)。如果 T对象存在，则 object.~T()叫做。最后，类似于 construct_at(addressof(object)) 的内容被调用以构建新的 T对象。

并不是说任何实现都会这样做，但您可以想象一个实现，在对 object.~T() 的调用之间和 construct_at(addressof(object)) , 重新初始化 no_object成员。这将是对先前由 object 占用的存储空间的“重用”。 .这意味着不满足 [basic.life]/8 的要求。

当然，您的问题的实际答案是:(1) 没有理由让实现做这样的事情，并且 (2) 即使实现做了，开发人员也会确保您的代码仍然运行好像 T对象被透明地替换。在标准库实现合理的假设下，您的代码是合理的，并且编译器开发人员不喜欢使用该属性破坏代码，因为这样做会不必要地激怒他们的用户。

但是，如果编译器开发人员倾向于破坏您的代码(基于未定义行为越多，编译器可以优化的越多的论点)，那么他们甚至可以破坏您的代码，甚至 <optional>头文件。用户需要将标准库视为一个“黑匣子”，它只保证标准明确保证的内容。因此，根据对标准的迂腐阅读，未指定是否尝试访问 ref。在第二个之后emplace调用具有未定义的行为。如果未指定它是否是 UB，则允许编译器在需要时开始将其视为 UB。

¹ 这是历史原因； C++17 要求 constexpr构造函数只初始化 union 的一个变体成员。此规则在 C++20 中被废除，因此 C++20 实现可以省略 no_object成员(member)。