为什么构造std :: optional <int>比std :: pair <int，bool>昂贵？

考虑以下两种可以表示“可选int”的方法：

using std_optional_int = std::optional<int>;
using my_optional_int = std::pair<int, bool>;

鉴于这两个功能...

auto get_std_optional_int() -> std_optional_int 
{
    return {42};
}

auto get_my_optional() -> my_optional_int 
{
    return {42, true};
}

... g ++干线和clang ++干线 （带有-std=c++17 -Ofast -fno-exceptions -fno-rtti）都会产生以下汇编：

get_std_optional_int():
        mov     rax, rdi
        mov     DWORD PTR [rdi], 42
        mov     BYTE PTR [rdi+4], 1
        ret

get_my_optional():
        movabs  rax, 4294967338 // == 0x 0000 0001 0000 002a
        ret

Godbolt.org上的实时示例

为什么只需要get_std_optional_int()三个mov指令，而get_my_optional()只需要一个指令movabs呢？这是QoI问题，还是在std::optional规范中有阻止此优化的内容？

还请注意，无论如何，这些功能的用户可能会被完全优化：

volatile int a = 0;
volatile int b = 0;

int main()
{
    a = get_std_optional_int().value();
    b = get_my_optional().first;
}

...结果是：

main:
        mov     DWORD PTR a[rip], 42
        xor     eax, eax
        mov     DWORD PTR b[rip], 42
        ret

libstdc ++显然未实现P0602“变量和可选变量应传播复制/移动琐碎性”。您可以使用以下方法进行验证：

static_assert(std::is_trivially_copyable_v<std::optional<int>>);

它对于libstdc ++失败，并通过libc ++和MSVC标准库（它确实需要一个专有名称，因此我们不必将其称为“ C ++标准库的MSVC实现”或“ MSVC STL”）。

当然，由于MS ABI，MSVC仍然不会通过optional<int>寄存器。

编辑：GCC 8版本系列中已解决此问题。

为什么只需要get_std_optional_int()三个mov指令，而get_my_optional()只需要一个指令 movabs呢？

直接原因是在寄存器中optional返回时通过隐藏指针pair返回的。为什么会这样呢？SysV ABI规范的3.2.3节“参数传递”中指出：

如果C ++对象具有非平凡的复制构造函数或非平凡的析构函数，则将通过不可见引用传递该对象。

整理出C ++的混乱optional并不是一件容易的事，但是至少在optional_base我检查过的实现类中，似乎有一个简单的复制构造函数。

Agner Fog在针对不同C ++编译器和操作系统的调用约定中说，复制构造函数或析构函数可防止在寄存器中返回结构。这解释了为什么optional不在寄存器中返回。

必须采取其他措施阻止编译器进行存储合并（将比一个字窄的立即值的连续存储合并到较少的较宽存储中，以减少指令数量）...更新： gcc错误82434--fstore-merging不工作可靠。

从技术上讲，即使std::is_trivially_copyable_v<std::optional<int>>是错误的，也允许进行优化。但是，它可能要求编译器找到不合理程度的“聪明”。同样，对于使用特定std::optional函数作为函数的返回类型的情况，可能需要在链接时而不是编译时进行优化。

执行此优化不会对任何（定义明确的）程序的可观察到的行为*产生任何影响，因此在as-if规则下是隐式允许的。但是，由于其他答案中已说明的原因，编译器尚未明确意识到该事实，因此需要从头开始进行推断。行为静态分析本质上是困难的，因此编译器可能无法证明此优化在所有情况下都是安全的。

假设编译器可以找到这种优化，那么它将需要更改该函数的调用约定（即，更改函数返回给定值的方式），这通常需要在链接时完成，因为调用约定会影响所有调用站点。或者，编译器可以完全内联函数，这在编译时可能会或可能不会。对于平凡可复制的对象，这些步骤将是不必要的，因此从这个意义上说，标准确实抑制了优化并使其复杂化。

std::is_trivially_copyable_v<std::optional<int>>应该是真的。如果为真，则编译器发现并执行此优化将容易得多。因此，回答您的问题：

这是QoI问题，还是在std::optional规范中有阻止此优化的内容？

都是。该规范使优化工作几乎很难找到，并且该实现还不够“聪明”，无法在这些限制下找到优化过程。

*假设您没有做过真正奇怪的事情，例如#define int something_else。