为什么C4062 Visual C++默认情况下警告关闭？

Question

根据 MSDN，当

• 使用枚举 时，Visual C++ 会发出 C4062 警告在 switch 中，并且
• 该枚举的至少一个元素没有标签，并且
• switch 中没有 default: 标签

现在对我来说这种情况当然值得警告——很有可能该元素处理不当。如果不需要对某些元素执行任何操作 - 开发人员可以提供空的 case 或 default。

默认情况下关闭此警告的原因可能是什么？

Answer 1

有些人（包括我自己）喜欢在构建时看到“0 警告”。如果您只不处理少数情况，那么添加一个空案例可能没问题，但如果您正在使用一个输入库，该库为您提供一个显示哪个键被按下的枚举，那么您真的想要 200 多个空案例吗？您不处理的密钥？

当然，您可能会说只添加一个空的默认情况，但是：

• 在上述情况下它并没有真正的语义意义
• 现在您只是邀请 C4061 （这一切在哪里结束？）

所以如果我默认收到这些警告，它真的会让我的强迫症感到紧张

Answer 2

如果默认情况下此警告处于打开状态，则在不编辑现有（已工作）代码的情况下，enum 可能无法始终保持可扩展性。例如

// (c) 2009
// header.h
enum E { a, b, c };
...
// legacy.cpp
switch(e)
{
case a:  ...
case b:  ...
case c:  ...
}

，假设 2 年后开发人员仅编辑 header.h。实现文件经过充分测试且未更改 (legacy.cpp)

// (c) 2011
// header.h
enum E { a, b, c, d, e };  // added 'd','e'

由于强制警告，legacy.cpp 可能会在以下位置出现大量警告： 和 e 未处理，这可能是不可取的。

Answer 3

这些警告可能是根据具体情况启用的。尝试使用 /Wall 编译 C++ 项目会从 Microsoft 自己的标头中产生数千个警告。

现在，您正在尝试调试一大段代码，您怀疑某处缺少 case 语句（或者您想排除这个假设）。然后启用 C4062。

如果你看得仔细的话，所有这些禁用的警告都是非常迂腐的，但它们可以用来追踪不明显的错误。您确实要启用 C4264 吗？

Answer 4

人们出于不同的原因使用枚举。

许多其他人（显然包括微软）会以较少审查的意图使用它们。它们只是一个命名值，它们的分组并不是很有趣。在防守方面，他们有很多基础。

有一些边缘情况，比如 GuyCook 的例子，没有人会因为收到警告而感到高兴。他说得对，没有人愿意看那些垃圾。在这种情况下，我已将处理代码放置在自己的 cpp 文件中，因此在不更改标头的情况下不会重新编译它。我希望有一种更方便的方法来解决这个问题，但我认为不存在。

我很欣赏语言（C#/Java？），因为它们能够通过注释忽略警告的特定实例。

事实上，您对它的省略感到困惑，这意味着您可能正在以设计中最有意义的方式使用它们。我个人认为枚举在耦合和内聚方面应该受到与类相同的审查。如果有人更改了枚举，则应审查代码。如果有人更改了您继承的类的接口，您会想知道这一点，不是吗？

不过，他们不必以这种方式使用它们。枚举只是一种工具，有些人更喜欢将它用作东西的同义词。 :)