Why is C4062 Visual C++ warning off by default?

问题

According to MSDN, Visual C++ can emit C4062 warning when

• and enumeration is used in switch and
• there's no label for at least one element of that enumeration and
• there's no default: label in the switch

Now to me such situation certainly deserves a warning - there's a good chance that the element in question is mishandled. If nothing has to be done for some elements - the developer can provide either an empty case or default.

What could be the reason why this warning is off by default?

回答1:

There are certain folk (in which I include myself) who like to see '0 Warnings' whenever they build. Adding an empty case might be OK if you're only not handling a few cases, but if you're working say with an input library which gives you an enum showing which key is down, do you really want 200+ empty cases for the keys you don't process?

Of course, you might say just add an empty default case, but:

• It doesn't really make semantic sense in the above case
• Now you're just inviting C4061 (where does it all end?)

So it would really set my OCD on edge if I got these warnings by default

回答2:

If this warning is ON by default, then enums may not remain extendable always, without editing the existing (already working) code. e.g.

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

Suppose, after 2 years developer edits just the header.h. The implementation file is well tested and not changed (legacy.cpp)

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

Due to the mandatory warning, the legacy.cpp may get flooded with warnings at places where d and e not handled, which may not be desirable.

回答3:

Those warnings are probably meant to be enabled on a case by case basis. Trying to compile a C++ project with /Wall yields thousands of warnings from Microsoft's own headers.

Now, you are trying to debug a large piece of code where you suspect that there is a case statement missing somewhere (or you want to rule out this hypothesis). You then enable C4062.

If you look well, all these disabled warnings are highly pedantic but have their use to track down obscure bugs. Do you really want to enable C4264 ?

回答4:

People use enums for different reasons.

Lots of other people (Microsoft included, obviously) will use them with much less scrutinized intention. They are just a named value, and their groupings aren't very interesting. In their defense, they have a lot of ground to cover.

There are some edge cases like GuyCook's example that nobody will be happy with getting a warning about. He's right that nobody wants to look at that crap. In cases like that I've placed handling code in its own cpp file so it wasn't recompiled without a change to the header. I wish there were a more convenient way to solve that problem, but I don't think there is.

I admire languages(C#/Java?) for their ability to ignore specific instances of a warning with annotations.

The fact that you are befuddled with its omission means you are probably using them in the way that they are the most meaningful in a design. I personally think enums should be given the same scrutiny as classes in regards to coupling and cohesion. If someone changes an enum, the code should be reviewed. If someone changed an interface on a class you inherited from, you'd want to know about that, wouldn't you?

They don't have to use them in that way, though. An enum is just a tool, some prefer to use it as a synonym for stuff. :)

来源：https://stackoverflow.com/questions/7916923/why-is-c4062-visual-c-warning-off-by-default