为什么 std::get for variant 会引发失败而不是未定义的行为？

Question

根据cppreference std::get for variant 如果variant 中包含的类型不是预期的类型，则抛出std::bad_variant_access。这意味着标准库必须检查每个访问 (libc++)。

做出这个决定的理由是什么？为什么它不是未定义的行为，就像 C++ 中的其他地方一样？我可以解决它吗？

Answer 1

为什么它不是未定义的行为，就像 c++ 中的其他地方一样？我可以解决它吗？

是的，有一个直接的解决方法。如果您不想要类型安全，请使用普通的union 而不是std::variant。正如您引用的参考文献中所说：

类模板 std::variant 表示类型安全的联合。

union 的目的是拥有一个可以从多种不同类型之一获取值的对象。在任何给定时间，只有一种类型的 union 是“有效的”，具体取决于分配了哪些成员变量：

union example {
   int i;
   float f;
};

// code block later...
example e;
e.i = 10;
std::cout << e.f << std::endl; // will compile but the output is undefined!

std::variant 概括了union，同时添加了类型安全性以帮助确保您只访问正确的数据类型。如果您不想要这种安全性，您可以随时使用union。

做出这个决定的理由是什么？

我个人不知道做出此决定的理由是什么，但您可以随时查看the papers from the C++ standardization committee 以了解该过程。

Answer 2

std::variant 的当前 API 没有未经检查的 std::get 版本。我不知道为什么它是这样标准化的。我说的都只是猜测。

但是，您可以通过编写*std::get_if<T>(&variant) 来接近所需的行为。如果当时variant 不持有T，std::get_if<T> 返回nullptr，因此取消引用它是未定义的行为。因此，编译器可以假设变体持有T。

---

在实践中，这并不是编译器要做的最简单的优化。与简单的标记联合相比，它发出的代码可能没有那么好。以下代码：

int const& get_int(std::variant<int, std::string> const& variant)
{
    return *std::get_if<int>(&variant);
}

发射this with clang 5.0.0:

get_int(std::variant<int, std::string> const&):
  xor eax, eax
  cmp dword ptr [rdi + 24], 0
  cmove rax, rdi
  ret

它正在比较变体的索引并在索引正确时有条件地移动返回值。即使索引不正确会导致 UB，clang 目前无法优化比较。

有趣的是，返回 int 而不是引用 optimizes the check away：

int get_int(std::variant<int, std::string> const& variant)
{
    return *std::get_if<int>(&variant);
}

发射：

get_int(std::variant<int, std::string> const&):
  mov eax, dword ptr [rdi]
  ret

---

您可以使用__builtin_unreachable() 或__assume 来帮助编译器，但是当您这样做时，gcc 目前是唯一的编译器capable of removing the checks。

Answer 3

做出这个决定的理由是什么？

这种问题总是很难回答，但我会试一试。

std::variant行为的很多灵感来自std::optional的行为，如std::variant、P0088的提案中所述：

本提案试图应用从optional...中吸取的经验教训...

您可以看到这两种类型之间的相似之处：

• 您不确定当前持有什么
  • 在optional 中要么是类型要么什么都不是 (nullopt_t)
  • 在variant 中，它要么是多种类型之一，要么什么都没有（参见valueless_by_exception）
• 对该类型进行操作的所有函数都标记为constexpr
  • 这似乎是巧合或只是良好的设计实践，但很明显，variant 在此方面遵循 optional 的领导（请参阅上面的链接提案）
• 它们都提供了一种检查空虚的方法
  • std::optional 隐式转换为bool，或者has_value 函数
  • std::variant 有 valueless_by_exception，它会告诉您变量是否为空，因为构造活动类型会引发异常
• 它们每个都提供了一种投掷和非投掷访问方式
  • std::optional 的潜在抛出访问权限是 value，它可能会抛出 bad_optional_access
  • std::variant 的潜在抛出访问权限是 get，它可能会抛出 bad_variant_access
  • 如果optional 为空，std::optional 的非抛出（我使用的术语有点松散）访问权限是 value_or，它可能会返回一个替代选项（您传入）
  • std::variant 的非抛出访问是 get_if，如果提供的索引或类型不正确，则返回 nullptr。

事实上，这些相似之处是如此刻意，以至于用于optional 和variant 的基类中的不一致是投诉的原因（请参阅this Google Groups discussion）

所以回答你的问题，它会抛出，因为optional 会抛出。请记住，应该很少遇到投掷行为；您应该使用带有变体的访问者模式，即使您确实调用了get，它也只会在您为其提供类型列表大小的索引或请求的类型不是活动类型时抛出。所有其他误用都被认为是格式错误的，应该会发出编译器错误。

---

至于为什么std::optional 抛出，如果你查看它的提议，N3793 有一个抛出访问器被宣传为对 Boost.Optional 的改进，std::optional 就是从 std::optional 诞生的。我还没有找到任何关于为什么这是一个改进的讨论，所以现在我来推测一下：提供满足两个错误处理阵营（哨兵值与异常）的抛出和非抛出访问器很容易，而且它还有助于从语言中消除一些未定义的行为，这样如果您选择走潜在的路线，就不会不必要地自取其辱。

Answer 4

我想我找到了！

似乎可以在proposal 中的“与修订版 5 的差异”下找到原因：

Kona 妥协：f !v.valid()，make get<...>(v) 和 visit(v) throw。

含义 - 变体必须进入“values_by_exception”状态。使用相同的if，我们总是可以抛出。

即使知道这种理性，我个人也想避免这种检查。 贾斯汀回答中的*get_if 解决方法对我来说似乎足够好（至少对于库代码而言）。