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

Question

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

case

或

default

。

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

Answer 1

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

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

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

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

可能会在

和

未处理的地方充斥着警告，这可能是不可取的。

Answer 3

这些警告可能需要根据具体情况启用。尝试使用

/Wall

编译 C++ 项目会从 Microsoft 自己的标头中产生数千个警告。

现在，您正在尝试调试一大段代码，您怀疑某处缺少

case

语句（或者您想排除这个假设）。然后启用 C4062。

如果你仔细观察，所有这些禁用的警告都非常迂腐，但可以用来追踪隐蔽的错误。您真的要启用 C4264 吗？

Answer 4

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

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

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

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

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

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