Google C++每周贴士 #147: 负责任地使用穷举`switch`

（原文链接：https://abseil.io/tips/147 译者：clangpp@gmail.com）

每周贴士 #147: 负责任地使用穷举switch

• 最初发布于：2018-04-25
• 作者：Jim Newsome
• 更新于：2020-04-06
• 短链接：abseil.io/tips/147

介绍

指定了编译选项-Werror以后，在switch一个enum类型数值的语句里，如果某个enum的枚举值没有对应的case，且没有default标签，那么编译就会失败。这通常被称作 穷举 或者 无默认值（defaultless） 的switch语句。

穷举switch语句提供了一个绝好的概念，以在编译期确保枚举类型的每个枚举值都被显式地处理了。然而，我们必须确保处理了落空（fall-through）的情况：变量（合法地）含有一个非枚举值，且要保证以下情况满足其一：

1. enum的所有者保证没有新的枚举值会被添加，
2. 在新的枚举值被添加的时候，enum的所有者有意愿且有能力修好我们的代码（例如，enum的定义是同一个项目的一部分），
3. enum的所有者不会被我们的构建破坏所影响（例如，其代码在另一个代码控制仓库中），而且我们愿意在更新到enum所有者最新版本代码的时候强制更新我们的switch语句。

最初的尝试

设想我们在写一个函数来把每个枚举值映射为一个std::string。我们决定使用穷举switch语句以确保不会忘记处理任意一个枚举值：

std::string AnEnumToString(AnEnum an_enum) {
  switch (an_enum) {
    case kFoo:
      return "kFoo";
    case kBar:
      return "kBar";
    case kBaz:
      return "kBaz";
  }
}

假设AnEnum确实只有三个枚举值，这段代码能够编译，并且看起来有预期的功能。然而，有两个重要的问题需要加以说明。

含有非枚举值的枚举类型

C++中，枚举类型被允许承载除显式声明的枚举值以外的值。如果一个整数类型恰好有足够的比特位数以表达每一个枚举值，那么所有的枚举类型都至少可以合法地接受该整数类型能够表达的所有值；有确定底层实现类型（例如，声明为enum class）的枚举类型，可以接受该类型可以表达的所有值。有的时候这一点被有意地用来以enum表达位域，或者用来表达编译代码时尚不存在的枚举值（如proto 3）。

那么，当an_enum不在我们处理的枚举值之中时会发生什么？

一般当switch语句没有case匹配switch的条件并且没有default分支的时候，代码会直接越过整个switch语句。这可能会导致意外的行为；在我们的例子中，它导致了未定义行为。在代码越过switch语句之后，它走到了函数结尾却没有返回一个值，这对于一个返回非空（non-void）类型的函数来说是未定义行为。

我们可以显式地处理代码越过switch语句的情况，以解决这个问题。这确保了我们在运行时总是得到定义好的、可预测的行为，并且继续受益于编译期检查，确保所有的枚举值都被显式地处理了。

在我们的例子中，我们将打印警告日志，然后返回一个哨兵值。另一个合理的选项，尤其是当我们确信该函数（现在）不能 接受一个非枚举值的时候，就是立即让程序崩溃（crash），并打印调试信息和堆栈信息，例如，用LOG(FATAL)。

std::string AnEnumToString(AnEnum an_enum) {
  switch (an_enum) {
    case kFoo:
      return "kFoo";
    case kBar:
      return "kBar";
    case kBaz:
      return "kBaz";
  }
  std::cerr << "Unexpected value for AnEnum: " << an_enum;
  return kUnknownAnEnumString;
}

对于an_enum的 任何 可能的数值，现在代码都确保了提供合理的行为，但还有可能有个问题。

新的枚举值被添加时会发生什么？

假设有人稍后想添加一个新的枚举值到AnEnum里。这会导致AnEnumToString编译失败。这是缺陷还是特性取决于谁拥有AnEnum和它们提供了什么样的保证。

如果AnEnum与AnEnumToString在同一项目中，那么添加新的枚举值的工程师在修好AnEnumToString的编译错误之前很可能没法提交代码。他很可能有意愿也有能力这么做。这种情况下使用穷举switch语句是好事：它成功地确保了switch语句被恰当地更新了，每个人都开心。

相似地，如果AnEnum是 另一个代码库 中的另一个项目的一部分，那这个破坏直到我们项目的工程师试图更新到新版本代码之前都不会浮现出来。如果我们期待那些工程师有意愿且有能力修好switch语句，那也还好。

然而，如果AnEnum属于 同一个代码库 中的另一个项目，那情况就更危险了。一个对AnEnum的修改可能导致我们的代码在最新版本被破坏，而且做出该修改的工程师也许没有意愿或没有能力帮我们修好。确实，如果有很多怼着AnEnum的穷举switch语句，那么把它们全修好可是个相当大的挑战。

因为这些原因，最好把穷举switch语句的使用场景限制在：要么我们拥有该enum类型，要么该类型的所有者显式地保证不会添加新的枚举值。

在我们的例子中，让我们假设AnEnum属于另一个项目，但是文档保证了不会有新的枚举值被添加。让我们添加一条注释，以便未来的读者理解我们的考量。

std::string AnEnumToString(AnEnum an_enum) {
  switch (an_enum) {
    case kFoo:
      return "kFoo";
    case kBar:
      return "kBar";
    case kBaz:
      return "kBaz";
    // 没有default。AnEnum的API保证了没有新的枚举值会被添加。
  }
  std::cerr << "Unexpected value for AnEnum: " << an_enum;
  return kUnknownAnEnumString;
}

结论

穷举switch语句可以是一个优秀的工具，确保所有的枚举值都被显式地处理了。为此要求我们：

• 显式地处理enum含有非枚举值，因此跳出整个switch语句的情况。具体来说，如果其所在的函数有返回值，我们必须确保该函数要么仍然返回一个值，要么以良好定义的且可调试的方式崩溃。
• 确保以下满足其一：
  • enum的所有者保证没有新的枚举值会被添加，
  • enum的所有者在添加新的枚举值的时候，有意愿且有能力修好我们的代码，
  • 如果我们的代码使用了穷举switch语句，并且被新添加的枚举值破坏了，owner的所有者不会因此而被阻碍其开发。

当把enum类型暴露给其他项目时，我们应该做到如下之一：

• 显式地保证没有新的枚举值会被添加，因此用户可以受益于穷举switch语句。
• 显式地保留未经通知而添加新的枚举值的权利，以阻止用户写穷举switch语句。一个惯用的方式是添加一个哨兵枚举值，且清楚地表明它不该被用于穷举switch语句；例如，kNotForUseWithExhaustiveSwitchStatements。

常见问题

• 为什么编译器允许在穷举switch之后省略return语句？

  如果有额外的步骤确保enum变量只能是其枚举值之一，那么省略最后的返回 可以 是安全的。在这种情况下，最好还是加一层保险，添加一个最终的return或LOG(FATAL)，但是有足够多的祖传代码没这么写，所以google3的默认编译选项允许没有最终返回的代码编译。

• 我要switch的枚举类型，已经到处都有穷举switch语句使用它了。既然其所有者已经事实上没法给它加新的枚举值了，我再多写一个穷举switch语句有什么关系？

  一般比起进一步增加维护者的负担，从所有者那儿拿到一个明确的策略会更好。

• 那protobuf里的枚举呢？

  权威指导请参见protobuf文档。

  在proto3的enum类型之上的穷举switch语句是不推荐的。解析器 不 保证enum字段会有枚举值。另外，在不引用特殊的（应该被视为protobuf工具内部实现细节的）哨兵枚举值的情况下，不可能写出针对proto3的enum类型的穷举switch语句。

  如果是你拥有的（或者其拥有者保证不会迁移到proto3，且不会添加新的枚举值的）proto2的enum类型，对其使用穷举switch语句是安全的，也是被protobuf团队推荐的。protobuf解析器保证enum字段会被赋予一个编译期的枚举值。不过还是要当心enum值不保证来自解析器的情况（例如，如果它是函数参数传进来的proto对象的一部分）。

• 那限定枚举（enum class）呢？

  本贴士里所有的东西适用于截稿之时的C++的所有枚举类型（也就是说，至少到C++20）。

参考资料

• Enum handling in protobuf generated code
• C++ enum specification