6

在实际代码中，构造函数可能非常复杂，因此emplaceastd::optional可以查询可选项本身的状态。当这种情况发生时，它通常会有点复杂，但这里有一个（人为的）最小的例子：

#include <iostream>
#include <optional>

struct Thing {
    Thing();
};

std::optional<Thing> othing;

Thing::Thing() {
    std::cout << othing.has_value() << std::endl;
}

int main() {
    othing.emplace();
}

对于所有三个主要的标准库实现，这会产生false. 换句话说，在 emplaceing 构造函数的执行过程中，可选项不包含 value。

从实现的角度来看，这意味着首先在原地构造值，然后设置一些簿记变量。这确实是MSVC、libc++和libstdc++的情况。

现在标准的相关部分为

[...] 当一个实例optional<T> 包含一个 value时，这意味着一个 T 类型的对象，称为可选对象的包含值，在可选对象的存储中分配。

有趣的是，这并没有使用明确定义的包含对象的生命周期（我想是因为这可以从外部强制结束，例如othing->~Thing()），而是在 storage 中分配的术语。该标准通常在动态内存的上下文中谈到分配，在这些情况下，分配显然发生在构造之前。

所以我认为提到的标准库实现不兼容，记账变量应该在构建开始之前设置。

在这种假设下，仍然存在一个问题：实现是否比标准更好，而不是后者需要修复或澄清？我不这么认为：在构建大型对象期间，访问已经初始化的子对象是完全有效且常见的，因此这对于包含在可选对象中的对象也应该是可能的。

那么我的考虑对吗？还是我对分配的术语的解释不正确？是否有反对我对 RightThing™ 做什么的观点的争论？

4

0 回答 0